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 time
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 funct
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 bo
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 woul
> 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, but
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 <
thierr
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 you
>
> 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
symbol
> 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
> 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]]]. That's
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 controlle
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, 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 m
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,
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 loose
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,
___
Python-ide
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
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 fundamental
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
>> without
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 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 program
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 time
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 som
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 to
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 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.
>
> And
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 op
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 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. W
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 to
30 matches
Mail list logo
