On Sun, May 17, 2020 at 07:17:00PM -, James Lu wrote:
> The Zen of Python states "there shouldn't be two ways to do the same thing."
No it doesn't.
--
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email
On Sun, May 17, 2020 at 09:04:50PM -, Alex Hall wrote:
> Some people (like myself, or the coworkers of [this
> person](https://mail.python.org/archives/list/python-ideas@python.org/thread/PLXOXKACKGXN4ZKISDVXLKMFIETWTF63/))
>
> just like to use asserts as a convenient way to check things.
On 2020-05-18 02:25, Greg Ewing wrote:
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
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 Sun, 17 May 2020 at 07:10, Christopher Barker wrote:
>
> > PS. Why wasn't a new builtin zip_strict() on the menu? I think I would have
> > given it at least +0.5, because of this rule of thumb.
>
> I would think that if zip_strict() added as a builtin, then zip_longest()
> should too.
>
>
On Mon, May 18, 2020 at 8:04 AM Richard Damon wrote:
> If you really what what you describe, add the following to your code:
>
> if not __debug__:
>
> raise AssertionError, "Please don't disable assertions"
>
> (This won't enable the assertions, but will let the user know that you
> need them
On 5/17/20 5:04 PM, Alex Hall wrote:
> Some people (like myself, or the coworkers of [this
> person](https://mail.python.org/archives/list/python-ideas@python.org/thread/PLXOXKACKGXN4ZKISDVXLKMFIETWTF63/))
> just like to use asserts as a convenient way to check things. We don't want
> asserts
Some people (like myself, or the coworkers of [this
person](https://mail.python.org/archives/list/python-ideas@python.org/thread/PLXOXKACKGXN4ZKISDVXLKMFIETWTF63/))
just like to use asserts as a convenient way to check things. We don't want
asserts to ever be turned off. Maybe there could be
On Sun, May 17, 2020 at 10:12 PM Ethan Furman wrote:
> On 05/17/2020 10:18 AM, Alex Hall wrote:
>
> > But it's good that we have the assert statement, because it makes it
> easy to write safe code and so people are encouraged to do so.
>
> I could not disagree more strongly with this. Every
On 05/17/2020 10:18 AM, Alex Hall wrote:
But it's good that we have the assert statement, because it makes it easy to
write safe code and so people are encouraged to do so.
I could not disagree more strongly with this. Every time I have seen assert
used it was in such a way that the
Many a python programmer have tired to see code written like:
def bar(a1, a2, options=None):
if options is None:
options = {}
... # rest of function
syntax if argument is not passed, evaluate {} and store to options
def foo(options:={}): pass
syntax if argument is not passed or is
On Sun, May 17, 2020 at 2:09 PM Nathan Schneider wrote:
> If you want a better metaphor: Some door handles include locks, others do
>> not. "Strict" ones have locks. So yes, it's possible to leave the lock in
>> the unlocked position, and then it functions pretty much the same as one
>>
On Sun, May 17, 2020 at 1:32 PM David Mertz wrote:
> On Sun, May 17, 2020 at 12:22 PM Nathan Schneider
> wrote:
>
>> Let me attempt a metaphor, which won't be perfect but may help:
>>
>> The safety one gets from strictness is a bit like driving a car wearing a
>> seat belt. It is not
On Sun, May 17, 2020 at 12:22 PM Nathan Schneider
wrote:
> Let me attempt a metaphor, which won't be perfect but may help:
>
> The safety one gets from strictness is a bit like driving a car wearing a
> seat belt. It is not fundamentally different from driving a car without a
> seat belt, and in
Steven D'Aprano writes:
> [Aside: despite what the Zen says, I think *protocols* are far more
> important to Python than *namespaces*.]
I think you misread the Zen. :-)
That-is-my-opinion-I-do-not-however-speak-for-its-author-ly y'rs,
___
Steven D'Aprano writes:
> constructed from
Thank you!
This is what I will use. "Construction" in programming has the strong
connotation of returning a new object (even though, say, int("1")
may return an interned object, so not new in a sense).
I'm not sure whether I'll rely on that
Andrew Barnert writes:
> >> The answer is that files are iterators, while lists are… well,
> >> there is no word.
> >
> > As Chris B said, sure there are words: File objects are *already*
> > iterators, while lists are *not*. My question is, "why isn't that
> > instructive?"
>
> Well,
On Sun, May 17, 2020 at 6:22 PM Nathan Schneider wrote:
> Let me attempt a metaphor, which won't be perfect but may help:
>
> The safety one gets from strictness is a bit like driving a car wearing a
> seat belt. It is not fundamentally different from driving a car without a
> seat belt, and in
On Sun, May 17, 2020 at 6:14 AM Rhodri James wrote:
> On 16/05/2020 17:14, Guido van Rossum wrote:
> > On Sat, May 16, 2020 at 1:26 AM Steven D'Aprano
> wrote:
> >
> >>> * zip(strict=True) +1
> >>> * zip(mode='strict') -0
> >>> * itertools.zip_strict() -0.5
> >>> * zip.strict()
On Sun, 17 May 2020 at 15:45, Thierry Parmentelat <
thierry.parmente...@inria.fr> wrote:
>
>
> > On 17 May 2020, at 16:31, Bernardo Sulzbach <
> berna...@bernardosulzbach.com> wrote:
> >
> > I would like to comment that the graphical presentation, at least in
> IDEs/where the font can be
> Before this goes too a big shaky bikeshed over almost nothing, let me
> point out that if you're looking to improve something in type
> annotations, I would suggest to look for true ugliness there.
> Something like Callable[[Dict[str, int], Sequence[Foo]],
> Dict[PrimaryKey, List[int]]].
> On 17 May 2020, at 16:31, Bernardo Sulzbach
> wrote:
>
> I would like to comment that the graphical presentation, at least in
> IDEs/where the font can be controlled, can be achieved using fonts:
>
> Precisely. Nicer than the arrow symbol, it would be to type "-" + ">" and get
> an arrow
>
> I would like to comment that the graphical presentation, at least in
> IDEs/where the font can be controlled, can be achieved using fonts:
>
Precisely. Nicer than the arrow symbol, it would be to type "-" + ">" and
get an arrow visually. The same can be done about getting >= as a single
Hello,
On Sun, 17 May 2020 14:31:34 +0200
Alex Hall wrote:
[]
> If we consider the arrow, what about ≤ instead of <=, ≥ instead of
> >=, ≠ instead of !=, × instead of `*`, and math.π instead of math.pi?
Before this goes too a big shaky bikeshed over almost nothing, let me
point out that if
I would like to comment that the graphical presentation, at least in
IDEs/where the font can be controlled, can be achieved using fonts:
https://stackoverflow.com/questions/41774046/enabling-intellijs-fancy-%E2%89%A0-not-equal-to-operator
On Sun, 17 May 2020 at 13:26, Thierry Parmentelat <
> math.π instead of math.pi
That is already possible, just not done in the standard library, no? Your
point still stands, but it's rather different to your other examples, which
are actual changes to syntax.
With regards to the actual proposal, I quite like the idea of being able to
use them,
On Sun, May 17, 2020 at 2:24 PM Thierry Parmentelat <
thierry.parmente...@inria.fr> wrote:
> well it’s all in the title
>
> the specific character that I am referring to is this one
>
> In [1]: print("\u2192”)
> →
>
> https://unicode-table.com/en/2192/
>
> ——
>
> just curious about how people
well it’s all in the title
the specific character that I am referring to is this one
In [1]: print("\u2192”)
→
https://unicode-table.com/en/2192/
——
just curious about how people would feel about taking better advantage of
non-ascii characters when that seems to make sense
fyi here’s how
Steven D'Aprano wrote:
> Proposal:
> 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.
> This mechanism could be a new function,or it could even be a magic local
> variable inside each
On 16/05/2020 17:14, Guido van Rossum wrote:
On Sat, May 16, 2020 at 1:26 AM Steven D'Aprano wrote:
* zip(strict=True) +1
* zip(mode='strict') -0
* itertools.zip_strict() -0.5
* zip.strict() -1 (but really, I'd like to make this -1e10)
I spent a significant amount of
> PS. Why wasn't a new builtin zip_strict() on the menu? I think I would
have given it at least +0.5, because of this rule of thumb.
I would think that if zip_strict() added as a builtin, then zip_longest()
should too.
And the fact that zip_longest was not added as a builtin made me think that
31 matches
Mail list logo
