On Fri, Oct 22, 2021 at 12:37:11PM -, Tom Pohl wrote:
> A question for the Python experts: What is the correct technical term
> for a functionality like "http.server", i.e., a module with an actual
> "main" function?
"A module which can be imported as a library, and also executed
as a scri
On Wed, Oct 20, 2021 at 11:30:50AM +0900, Stephen J. Turnbull wrote:
> Steven D'Aprano writes:
>
> > Ironically, Ricky's in-fun suggestion that we use the tilde operator for
> > swapcase was the only suggestion in these two threads that actually met
> > the
On Tue, Oct 12, 2021 at 05:30:13PM -0700, Guido van Rossum wrote:
> I would also like to remind various other posters that sarcasm is *not* a
> good way to welcome newbies. The name of the list is python-ideas, not
> python-ideas-to-shoot-down-sarcastically.
Guido, it isn't fair of you to jump in
On Wed, Oct 20, 2021 at 11:10:52AM +1100, Chris Angelico wrote:
> On Wed, Oct 20, 2021 at 11:02 AM Steven D'Aprano wrote:
> > Ironically, Ricky's in-fun suggestion that we use the tilde operator for
> > swapcase was the only suggestion in these two threads that actually
On Sun, Oct 17, 2021 at 05:02:23PM -0700, Guido van Rossum wrote:
> On Sun, Oct 17, 2021 at 4:38 PM Steven D'Aprano wrote:
>
> > Right-o, the old "heterogeneous tuples versus homogeneous lists"
> > distinction, I remember that from the old 1.5 days. I haven&#x
On Tue, Oct 12, 2021 at 05:10:45PM -0700, Jelle Zijlstra wrote:
> Your other post mostly attracted sarcastic replies, so I'll be more direct:
> It's highly unlikely that this will go anywhere.
Jelle, the second part of your sentence may be true, but the first part
is not. It is unfair and inaccu
On Mon, Oct 18, 2021 at 10:20:17AM -, Mathew Elman wrote:
> despite a driving idea of python syntax being readability in
> english, the function signature is distinctly not english.
Python's syntax was not really modelled on English, as far as I can
tell. It was (I think) modelled more on P
We don't have tuple comprehensions, and this proposal isn't to add them,
so this post is edging into off-topic for the thread so feel free to
skip it.
On Sat, Oct 16, 2021 at 03:18:20PM -0400, David Mertz, Ph.D. wrote:
> Rather, I'm concerned with readability and programmer expectations. Tuples
On Sun, Oct 17, 2021 at 02:48:48PM +0100, Rob Cliffe via Python-ideas wrote:
> I'm sending this to python-list because my emails to python-dev keep
> getting bounced back (after a few days delay). I've no idea why.
If you are getting a bounce message, as opposed to the email just
disappearing i
We can already easily simulate your first alternative in a generator
comprehension:
(x for it in its for x in it)
# equivalent to
def gen(its):
for it in its:
for x in it:
yield x
so anyone who wants that behaviour can easily get it. So unpacking
On Sat, Oct 16, 2021 at 02:49:42PM +0100, Paul Moore wrote:
> I'd be more likely to just remove the types (the type checking
> equivalent of `#noqa` when you don't agree with what your style
> checker says).
Type annotations are still useful to the human reader, even if the type
checker is absen
On Sat, Oct 16, 2021 at 11:42:49AM -0400, Erik Demaine wrote:
> I guess the question is whether to define `(*it for it in its)` to mean
> tuple or generator comprehension or nothing at all.
I don't see why that is even a question. We don't have tuple
comprehensions and `(expr for x in items)` i
On Sat, Oct 16, 2021 at 10:56:07AM -0400, David Mertz, Ph.D. wrote:
> POn Sat, Oct 16, 2021, 10:10 AM Erik Demaine
>
> > (*it1, *it2, *it3) # tuple with the concatenation of three iterables
> > [*it1, *it2, *it3] # list with the concatenation of three iterables
> > {*it1, *it2, *it3} # set with
On Sat, Oct 16, 2021 at 09:19:26AM -0400, Erik Demaine wrote:
> To me (a mathematician), the existence of this magic in def, class, import,
> etc. is a sign that this is indeed useful functionality. As a fan of
> first-class language features, it definitely makes me wonder whether it
> could b
On Sat, Oct 16, 2021 at 09:54:13AM +0100, Alex Waygood wrote:
> > On 16 Oct 2021, at 06:13, Steven D'Aprano wrote:
> > Be careful about believing what you are told.
>
> Indeed, MyPy will correctly raise errors if you assign {None: []} to a
> variable annotated with
On Fri, Oct 15, 2021 at 06:17:12PM +0200, Sebastian M. Ernst wrote:
> Data = Dict[str, Number]
>
> @typechecked
> def foo(bar: Data):
> print(bar)
> ```
>
> Yes, this is using run-time checks (typeguard), which works just fine.
> Only strings as keys and Number objects as values are going thr
On Fri, Oct 15, 2021 at 06:37:04PM -0400, Ricky Teachey wrote:
> You say a soft keyword isn't an option and I understand why, but what about
> one that is incredibly unlikely to have been used very often? I'm thinking
> of just a simple double underscore:
>
> >>> a = __
> >>> a
> 'a'
I frequentl
On Thu, Oct 14, 2021 at 11:15:52PM +1100, Chris Angelico wrote:
> On Thu, Oct 14, 2021 at 11:03 PM Jeremiah Vivian
> wrote:
> >
> > Results are in (tested
> > `next(iter(d))`/`next(iter(d.values())`/`next(iter(d.items())` and their
> > `next(reverse())` counterparts):
> > `*` / `/` implemented i
On Thu, Oct 14, 2021 at 08:36:37AM -, Jeremiah Vivian wrote:
> So I implemented these functions as operators in a downloaded source
> of CPython... the differences are insane! (Sorry if this produces
> nested quotes)
> > >>> import timeit
> > # d + 1 vs list(d.values())[0]: 2133x speedup
d
On Thu, Oct 14, 2021 at 12:32:57AM +0400, Abdulla Al Kathiri wrote:
> Today I found myself write a function that returns a tuple of list of
> list of strings (tuple[list[list[str]], list[list[str]]]). Wouldn’t it
> easier to read to write it like the following:
> ([[str]], [[str]])?
Not really
On Wed, Oct 13, 2021 at 12:05:35AM -, MarylandBall Productions wrote:
> I would think `~string` could be good for a shorthand way to convert a
> string to an integer, considering you’re “inverting” the string to
> another type
How is `int(string, 16)` "inverting"?
Inverting means to flip o
On Tue, Oct 12, 2021 at 11:50:27PM -, Jeremiah Vivian wrote:
> I posted a previous thread about overloading the unary `+` operator in
> strings with `ord`, and that expanded to more than just the unary `+`
> operator. So I'm saying now, there should be these implementations:
Did you actuall
On Wed, Oct 13, 2021 at 09:22:09AM +1100, Chris Angelico wrote:
> Mathematicians and programmers both extend
> operators to new meanings, but only where it makes sense.
In fairness, mathematicians typically just invent new symbols, when
they're not repurposing existing symbols for totally unrela
On Tue, Oct 12, 2021 at 11:36:42PM +1100, Chris Angelico wrote:
> You haven't given any reason why unary plus should imply ord().
I think the question Chris is really asking is why should unary plus
return ord() rather than any other function or method.
We could make unary plus of a string equa
Shouldn't your safe_map raise RuntimeError rather than ValueError?
That's what PEP 479 does *wink*
https://www.python.org/dev/peps/pep-0479/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@pyt
On Tue, Oct 12, 2021 at 06:34:06AM -, Jeremiah Vivian wrote:
> So `ord` is already a really fast function with (last check before
> this thread was posted) 166 nsec per loop. But I'm wondering... doing
> `ord(a)` produces this bytecode:
>
> > 2 4 LOAD_NAME1 (ord)
>
On Mon, Oct 11, 2021 at 06:59:14PM -0400, Erik Demaine wrote:
> In the end, I feel like the main case I want to use a `first` and `last`
> functions on are `dict`s;
"I want to use first on dicts" is not really a use-case. Presumably
you're not just doing:
d = {key: value, ...}
who_care
On Sat, Oct 09, 2021 at 08:16:58PM -0600, Finn Mason wrote:
> I feel like there could be a better way to define versions. There's no real
> standard way to specify versions in Python, other than "use semantic
> versioning."
It is a common myth that Python uses semantic versioning. It doesn't.
ht
On Sat, Oct 09, 2021 at 08:16:58PM -0600, Finn Mason wrote:
> import sys
> if sys.version_info < (3, 6):
> # Yell at the user
Please, version checking is usually an anti-pattern! You should use
feature detection whenever possible, not version checking.
For example, if you need the lcm funct
On Wed, Oct 06, 2021 at 03:42:28PM +0100, Alex Waygood wrote:
> > Whether they are added to dict or itertools, there are still nine of
> > them
>
> No, the suggestion was to add two functions to itertools (first() and
> last(), which would work with any iterable, not just dicts), rather
> than
On Fri, Oct 08, 2021 at 01:42:35PM -0700, Christopher Barker wrote:
> Anyway, I do see the benefit of adding first() to itertools -- there really
> is a key problem with:
>
> next(iter(an_iterable))
>
> for newbies -- you can get really really far in Python without ever having
> to call either
On Fri, Oct 08, 2021 at 01:42:35PM -0700, Christopher Barker wrote:
> It really ius frustrating how often we repeat entire conversations on this
> list :-(
That's because y'all don't just admit I'm right the first time *wink*
> But last time, one of the use cases was "get a random item from a d
On Sun, Oct 10, 2021 at 01:51:52AM +0900, Stephen J. Turnbull wrote:
> Christopher Barker writes:
>
> > But last time, one of the use cases was "get [an arbitrary] item
> > from a dict", and there really is not a terribly easy (and
> > efficient) way to do that now.
>
> What's wrong with thedi
On Wed, Oct 06, 2021 at 11:17:07AM -0400, Eric V. Smith wrote:
> I think we can rely on dicts being ordered as a language guarantee for
> the rest of time.
Indeed. That's official and documented.
"Changed in version 3.7: Dictionary order is guaranteed to be insertion
order. This behavior was a
On Wed, Oct 06, 2021 at 11:11:09AM +0100, Alex Waygood wrote:
> > The temptation to insist "see, YAGNI!" at this point I shall resist.
>
> *You* might not need it, but I've seen it come up a lot on Stack
> Overflow, and all too often people end up going for the much less
> efficient solution. I
On Tue, Oct 05, 2021 at 08:45:55AM +0100, Alex Waygood wrote:
> I think there definitely should be a more obvious way to do this
> (specifically the first and last keys/values/items of a dictionary
What's your use-case for caring what the first and last key in a dict
is?
> An anti-pattern yo
Hi Laurent,
It is not clear to me what you mean by "filter by indices".
On Sat, Oct 02, 2021 at 10:25:05PM +0200, Laurent Lyaudet wrote:
> The idea is to filter a list by indices :
[...]
> Since filter() returns an iterator instead of a list, it could do what
> is needed... if the callback had a
On Sat, Oct 02, 2021 at 08:33:59PM -0600, Finn Mason wrote:
> I've found that the `if __name__ == "__main__"` idiom is unintuitive and
> feels unnecessary,
The Python community thinks nothing of writing code with metaclasses,
functions and classes as first-class citizens, recursion, parallisatio
On Sun, Oct 03, 2021 at 01:26:06AM -, Debashish Palit wrote:
> The floatify solution is a bit involved - using map inside a list
> comprehension. Usually list comprehensions replace the usage of map.
> Also floatify requires 5 extra lines of code (putting `return` on the
> same line is not
On Sat, Oct 02, 2021 at 09:22:04AM +, Zbigniew Jędrzejewski-Szmek wrote:
> A nice bonus is that this scheme is very close to main() in C/C++/Java
> and other compiled languages, so users coming in from those languages
> will understand this without further explanation.
I don't think they will
On Sat, Oct 02, 2021 at 10:17:12AM -0700, Paul Bryan wrote:
> As I understand, the arguments for:
> - let's get rid of boilerplate, that many (esp. beginners) may not
> understand
The proposal doesn't get rid of boilerplate, it just changes it from one
form to another.
The current idiom uses an
On Sat, Oct 02, 2021 at 05:13:01PM +0100, Alex Waygood wrote:
> I disagree that "it teaches a lot about how Python works" is a good
> reason to keep things the way they are. If you applied this principle
> more broadly, it would seem to be an argument in favour of complexity
> in most situation
On Sat, Oct 02, 2021 at 07:57:48AM -0700, Guido van Rossum wrote:
> No, it would also have to increment the reference count of each item (since
> blist owns a reference to each). That's what makes this slow.
Ahaha, of course, I forgot about the ref counting.
> > There are lots of other variants
On Sat, Oct 02, 2021 at 01:06:46PM -, Debashish Palit wrote:
[...]
> Consider a number radix conversion software. It needs to accept the
> input number as a string (say '15A' in base 12). When we provide it a
> base 10 number, it would also be a string.
Why a string? That's an unusual API.
On Sat, Oct 02, 2021 at 01:21:46PM -, Debashish Palit wrote:
> Steven D'Aprano wrote:
> > On Sat, Oct 02, 2021 at 02:53:03AM -, Debashish Palit wrote:
> > > There is no need of a three_way_flag - just use a conditional
> > > expression instead of a
This half-baked idea is inspired by this thread here:
https://mail.python.org/archives/list/python-ideas@python.org/message/5LGWV3YLCNBVSL4QHQKJ7RPNTMWOALQA/
which in turn was inspired by this Stackoverflow post:
https://stackoverflow.com/questions/56966429/getting-pairs-of-one-item-and-the-rest
On Sat, Oct 02, 2021 at 01:15:28AM -0400, Jonathan Crall wrote:
> On Sat, Oct 2, 2021, 12:05 AM Chris Angelico wrote:
> > But it's ONLY necessary when a single Python file is used as both a
> > script and a module. Bear that in mind.
>
> That's effectively every module I write. I don't think th
On Sat, Oct 02, 2021 at 12:45:33PM +0200, Laurent Lyaudet wrote:
> def enumerate_with_rest(my_list):
> for i, item in enumerate(my_list):
> yield i, item, my_list[:i] + my_list[i + 1:]
So if you called it on the list ['a', 'b', 'c', 'd'] it would yield:
0, 'a', ['b', 'c', 'd']
On Sat, Oct 02, 2021 at 02:17:32AM -, Debashish Palit wrote:
> The method need not take care of every variation. Currently there is
> no method to check for a float in a string even without formatting.
Right, because no method is needed. If you want to convert something to
a float (whether
On Sat, Oct 02, 2021 at 02:53:03AM -, Debashish Palit wrote:
> There is no need of a three_way_flag - just use a conditional
> expression instead of an if-elif-else block,
Of course you need a three way flag if your function returns a three way
flag. It returns False for ints, True for floa
On Fri, Oct 01, 2021 at 08:56:39AM -, dpali...@outlook.com wrote:
> It would be nice to have a string method that checks for a float.
> Currently there is no support for this, either built-in or in the
> standard library. There is a thread, dating back to Dec 2020, that
> proposes a trivial
On Fri, Oct 01, 2021 at 03:35:26PM -0400, Jonathan Crall wrote:
> My motivation for writing this suggestion is in an attempt to stop a common
> anti-pattern, where instead of defining a `main` function (or a function by
> any other name) an simply calling that by adding the above two lines, a lot
On Fri, Oct 01, 2021 at 06:43:40AM -0300, Soni L. wrote:
> Look for the clarification post we posted as a reply to the original post.
Who is "we"? If you are posting this in collaboration with other people,
it would be polite to introduce them.
--
Steve
___
On Thu, Sep 30, 2021 at 01:25:42PM -0300, Soni L. wrote:
> def foo():
> raise Bar
> def baz() with Bar:
> foo()
> baz()
>
> would make a RuntimeError, because foo raised a Bar and the VM sees that
> Bar is in baz's with.
So the syntax "with SomeException" in a functio
Let's get to the fundamental problem with this. It is DWIM magic, and
you haven't (as far as I have seen) yet specified how we are supposed to
use it or predict how it is supposed to work.
Here is your syntax again:
> > def a_potentially_recursive_function(some, args) with
> > ExceptionWeC
On Thu, Sep 30, 2021 at 07:41:47AM -0300, Soni L. wrote:
> You misnderstand exception hygiene. It isn't about "do the least stuff
> in try blocks", but about "don't shadow unrelated exceptions into your
> public API".
I disagree with that. I don't think that "exception hygiene" is a common
term
On further thought, maybe something like this is what you are looking
for?
https://code.activestate.com/recipes/580808-guard-against-an-exception-in-the-wrong-place/
This allows you to replace one or more kinds of exceptions with another
specified exception (defaults to RuntimeError) using a co
On Thu, Sep 30, 2021 at 12:03:37AM -0300, Soni L. wrote:
> > Only some.user_code is guarded by the try block. If it turns out that
> > code_we_assume_is_safe is not actually safe, and fails with an
> > exception, it won't be caught by the try block and you will know about
> > it.
>
> Except no
On Wed, Sep 29, 2021 at 02:09:03PM -0700, Guido van Rossum wrote:
> Over in typing-sig we're considering a new syntax for callable *types*,
> which would look like (int, int, str) -> float. A matching syntax for
> lambda would use a different arrow, e.g. (x, y, z) => x+y+z.
I like arrow operators
In Soni's original code snippet, there is a clear separation of code
that is inside the try block from code that is outside the try block:
> def a_potentially_recursive_function(some, args):
> try:
> some.user_code()
> except ExceptionWeCareAbout as exc:
> raise RuntimeError fro
On Wed, Sep 29, 2021 at 10:01:52PM -0300, Soni L. wrote:
> So uh, this is a hardly at all fleshed out idea, but one thing we really
> don't like about python is having to do stuff like this so as to not
> swallow exceptions:
Is that the Royal We or are you actually speaking on behalf of other
pe
On Wed, Sep 29, 2021 at 09:11:35AM -, Dominik Vilsmeier wrote:
> * `sorted(items, key=?['key'])`
> * `filter(? > 0, items)`
> * `map(f'{?:.3f}', items)`
I think those are massively more cryptic and hard to read than an
explicit lambda. Being too terse is worse that being too verbose:
consid
On Fri, Sep 24, 2021 at 11:23:00PM -0700, Guido van Rossum wrote:
> > Is there no room for making it easier to do this with less invasive
> > changes to the stdlib, or are Steven d'A's "heroic measures in an
> > import hook" the right way to go?
> >
> > Other Steve
>
>
> There’s room for that, b
On Fri, Sep 24, 2021 at 10:39:32PM -0700, Christopher Barker wrote:
> Now that's a PEP I could get behind.
You mean, like this PEP? *wink*
> Adding one feature to unittest doesn't seem worth it to me
I don't think this PEP directly proposes any new features to unittest.
If it is accepted, who
This proposal sounds very promising. Some observations/questions follow.
On Fri, Sep 24, 2021 at 02:04:21PM +0300, Noam Tenne wrote:
> Assertion failed:
>
> sc.val['d'] == f
> | ||
> | eFalse
> |
> {'d': 'e'}
Can we see what the output would look like
On Fri, Sep 24, 2021 at 07:45:41PM -0700, Christopher Barker wrote:
> 1) this should be part of a test framework, not something built in to
> exceptions. Pytest has shown that it can be done without any language
> changes.
Pytest needs to take heroic measures in an import hook to re-write your
as
On Sat, Sep 18, 2021 at 03:50:00PM -0700, Christopher Barker wrote:
> Folks are not surprised by:
>
> >> 2 * 3 == [2] * 3
>
> False
>
> Because 2 is not only a different type than [2] but because they are
> different values as well.
What counts as a value? In some programming languages, 2.0 !=
On Sat, Sep 18, 2021 at 11:24:40AM +0900, Stephen J. Turnbull wrote:
> Steven D'Aprano writes:
>
> > But I don't think it would be a big problem unless the caller was mixing
> > calls to gamma with int and float arguments.
>
> You mean `factorial` here, ri
barry_as_FLUFL is a joke, not a serious feature.
Why do you want to enable it, then remove it? What's your motivation for
this feature?
--
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le.
On Fri, Sep 17, 2021 at 11:12:45AM +0300, Serhiy Storchaka wrote:
> 17.09.21 05:23, Steven D'Aprano пише:
> >>>> factorial(23) == better_factorial(23)
> > False
> >
> > The problem is that since floats only have about 17 significant figures
> >
On Thu, Sep 16, 2021 at 06:33:58PM -, Jonatan wrote:
> Currently, math.factorial only supports integers and not floats,
> whereas the "mathematical" version supports both integers and floats.
That's questionable.
(Warning: maths geek post follows.)
Mathematicians typically only use the n
On Wed, Sep 15, 2021 at 12:02:04PM -0700, Guido van Rossum wrote:
> To make chdir() return a context manager *and* keep it working without
> calling `__enter__`, it would have to call `getcwd()`, which I've heard is
> expensive.
>
> So I don't think that would work, alas.
How expensive would it
On Wed, Sep 15, 2021 at 08:53:21PM +1000, Chris Angelico wrote:
> Sometimes there is no valid path to something,
I don't understand what you mean by that. If there is no valid path to
something, where exactly are you cd'ing to, and how does it help you
with the thing that has no valid path to i
On Wed, Sep 15, 2021 at 11:56:17AM +0200, Marc-Andre Lemburg wrote:
> > - The context manager could be made more elaborate, e.g. adding optional
> > logging for debugging purposes.
>
> We could add a logger parameter to the context manager for
> this to customize the logger, or simply use the d
On Tue, Sep 14, 2021 at 11:31:43AM +0400, m...@dyatkovskiy.com wrote:
> Thus I have collection of options and some of them are empty or None.
> In order to get rendered command line options string I use “compress”
> in conjunction with “join":
>
> >>> opts = " ".join(compress(flags, flags))
Wh
Over on Discuss, there's a small discussion about the "lambdas in for
loop" problem described in the FAQs.
https://discuss.python.org/t/make-lambdas-proper-closures/10553
https://docs.python.org/3/faq/programming.html#why-do-lambdas-defined-in-a-loop-with-different-values-all-return-the-same-res
On Sat, Sep 11, 2021 at 02:37:25PM -0400, Juancarlo Añez wrote:
> David,
>
> It seems I didn't state clearly enough my original statement, which is that
> software will *_always_ *fail, even because of faulty hardware components,
> or cosmic rays.
If you expect your software to be resilient given
On Sat, Sep 11, 2021 at 02:30:10PM -0400, Juancarlo Añez wrote:
> *invariant* cond: etc
A software invariant is still an assertion.
In another post, I semi-suggested a new (soft) keyword:
unless condition:
# block
raise Exception
But really, it's just an "if not".
if n
On Fri, Sep 10, 2021 at 06:48:42PM -0400, Juancarlo Añez wrote:
> I agree that assertions can be and are abused.
>
> And I'm not too interested in DBC, nor in preconditions, nor in contracts.
In your first post you said:
[quote]
This is in the context of "Design by contrast" (DBC) as a useful
On Thu, Sep 09, 2021 at 09:16:23AM -0700, Guido van Rossum wrote:
> assert cond, raise=ExcType(args)
How about this?
if not cond: raise ExcType(args)
This is 100% backwards compatible, doesn't not abuse `assert`, will not
be removed when running under -O, and takes exactly the same numbe
On Thu, Sep 09, 2021 at 12:53:34PM -0400, Ricky Teachey wrote:
> I have never heard of DBC and don't have a clue what is stands for. I am
> not a pro software developer.
DBC stands for "Design By Contract", it is a methodology for developing
software.
https://en.wikipedia.org/wiki/Design_by_con
On Thu, Sep 09, 2021 at 12:02:13PM -0400, Juancarlo Añez wrote:
> Steven,
>
> The purpose is to make it easier to make software more resilient.
Thank you but I understand the purpose of DBC and how it can be helpful
for writing resilient software. If you search the archives, you will see
that n
On Tue, Sep 07, 2021 at 11:12:37AM -0400, Juancarlo Añez wrote:
> I won't propose a syntax, but I think it would be useful if *assert* could
> raise an exception different from *AssertionError*.
>
> This is in the context of "Design by contrast" (DBC) as a useful companion
> to "Test-driven develop
Hi Leonardo,
On Tue, Sep 07, 2021 at 02:31:26AM -, Leonardo Freua wrote:
> When writing some unit tests with the standard Unittest library, I
> missed being able to create parameterized tests.
Could you please explain what you mean by "parameterized tests", and how
you would use a decorato
On Fri, Sep 03, 2021 at 05:31:33PM -0700, Guido van Rossum wrote:
> I know you don't. My point with that example was to show how unlikely it is
> that someone would write that in the first place (since the code would
> always fail rather than in specific cases).
I have code that does something si
On Fri, Sep 03, 2021 at 09:32:26AM -0700, Guido van Rossum wrote:
> The question is, would anyone ever want to make a distinction between the
> two in *real* code? I find it unlikely that someone would write
>
> try:
> sum(x, y, z)
> except TypeError:
> ...
Not for sum specifically, but
On Fri, Sep 03, 2021 at 03:43:03PM +1000, Chris Angelico wrote:
> Yes, although I'd love to have a good term for "there is only ever one
> object of this type AND VALUE", rather than "there is only one object
> of this type", so that True and False could be discussed the same way
> as singletons.
On Thu, Sep 02, 2021 at 04:54:45PM +0900, Stephen J. Turnbull wrote:
> Steven D'Aprano writes:
> > On Thu, Sep 02, 2021 at 04:04:40PM +0900, Stephen J. Turnbull wrote:
> >
> > > You may not need to teach them about singletons, though.
> >
> > It
Kevin Mills suggested:
> > > d = {1: {2: {3: 4}}}
> > > keys= 1,2,3
> > > print(d[*keys])
> > > d[*keys] = None
> > > print(d)
> > >
> > > Hopefully it's clear from that example what I'm suggesting.
MRAB replied:
> > Would that be equivalent to d[keys[0], keys[1], keys[2]]?
> >
> > If so, it wo
On Thu, Sep 02, 2021 at 04:04:40PM +0900, Stephen J. Turnbull wrote:
> You may not need to teach them about singletons, though.
It's hard to teach why `is` works with None, but not with 1.234 or [],
without talking about the object model and singletons.
To say nothing of why it works with 0 and
On Tue, Aug 31, 2021 at 05:17:35PM -0700, Matthias Bussonnier wrote:
> Basically anything that implements __eq__ and assumes it will be
> compared only against things that are of the same type will not be
> happy to be compared with None using ==.
I agree with Oscar that the various objects you l
On Wed, Sep 01, 2021 at 02:33:20PM -0700, Brendan Barnwell wrote:
> There is nothing wrong, in my view, with a teaching approach that
> tells people to do a thing one way and then later tells them to move on
> to
> a different way.
This! +1
https://en.wikipedia.org/wiki/Lie-to-chi
On Wed, Sep 01, 2021 at 12:07:52PM -0400, David Mertz, Ph.D. wrote:
> On Wed, Sep 1, 2021, 11:55 AM Christopher Barker
> wrote:
>
> > Can you redefine the name, “None” in ancient Python?
> >
>
> I didn't show it in my earlier post, but in Python 1.0.1, you an indeed
> rebind the name None (much
On Wed, Sep 01, 2021 at 03:40:37PM +0200, Peter Otten wrote:
> Instead of removing it you might add a filter to get a similar effect:
[...]
> >>> warnings.filterwarnings("always", "woof!")
Unfortunately that's too aggressive. In my use-case, `bark` will be
called many, many times in a loop, an
On Tue, Aug 31, 2021 at 09:49:36AM -0400, Calvin Spealman wrote:
> I think the provenance of the "is None" rule comes from before None was a
> guaranteed singleton. In older versions of Python, it was *possible* to
> instantiate more instances of None.
I don't suppose you can show how that works?
Maybe I'm missing something, but I don't think that there is anyway to
remove a warning from the warnings filter list so that it will be shown
again.
Example:
>>> import warnings
>>> warnings.warn("something happened")
:1: UserWarning: something happened
>>> warnings.warn("somet
On Tue, Aug 31, 2021 at 06:18:15PM -0400, Todd wrote:
> You insist that both approaches should be treated as equally valid. But
> they simply aren't. In the real world, where people are trying to do almost
> anything useful with python, approach 2 is too dangerous to rely on.
In fairness to Nick,
On Tue, Aug 31, 2021 at 11:15:22AM -0700, Nick Parlante wrote:
> As a practical matter, the IDEs just default to having PEP8 checking on,
> and they do it in a very visual way - akin to a text editor which puts
> little squiggles under words it thinks are misspelled.
>
> This maybe sounds annoyin
On Wed, Sep 01, 2021 at 10:29:24AM +1000, Chris Angelico wrote:
> In the classic demonstration that 0.1 + 0.2 != 0.3, the problem isn't
> equality, it's that none of those values is what you think it is.
That is a wonderful way of putting it.
--
Steve
___
On Tue, Aug 31, 2021 at 12:35:05PM -0700, Nick Parlante wrote:
> You will be relieved to know that we have great fun showing them how ==
> does not work for floating point numbers. It is super memorable how that
> all comes unglued.
Of course `==` works for floating point numbers. For floats, `x
401 - 500 of 2996 matches
Mail list logo
