On Thu, 9 Apr 2020 20:56:56 -0700
"Gregory P. Smith" wrote:
> On Wed, Apr 8, 2020, 10:37 AM Antoine Pitrou wrote:
>
> > On Wed, 8 Apr 2020 10:18:47 -0700
> > Guido van Rossum wrote:
> > >
> > > > But when I leave "large" temp objects hanging and
> > > > give a rip, I already stick in "del"
On 10/04/20 8:30 am, Soni L. wrote:
Sometimes, you have an API:
@abc.abstractmethod
def get_property_value(self, prop):
"""Returns the value associated with the given property.
Args:
prop (DataProperty): The property.
Returns:
The
On 2020-04-10 7:05 a.m., Greg Ewing wrote:
On 10/04/20 8:30 am, Soni L. wrote:
Sometimes, you have an API:
@abc.abstractmethod
def get_property_value(self, prop):
"""Returns the value associated with the given property.
Args:
prop (DataProperty): The
On 10/04/2020 12:43, Soni L. wrote:
it's actually fairly common to deal with KeyError instead of using
dict.get or w/e.
KeyError is also raised when your code has a bug and your assumptions
got broken.
it's fairly easy to get the two different KeyErrors mixed up, at least.
So don't do that
On 2020-04-10 9:40 a.m., Rhodri James wrote:
On 10/04/2020 12:43, Soni L. wrote:
it's actually fairly common to deal with KeyError instead of using
dict.get or w/e.
KeyError is also raised when your code has a bug and your assumptions
got broken.
it's fairly easy to get the two different
On Fri, Apr 10, 2020 at 8:05 PM Greg Ewing wrote:
>
> On 10/04/20 8:30 am, Soni L. wrote:
> > Sometimes, you have an API:
> >
> > @abc.abstractmethod
> > def get_property_value(self, prop):
> > """Returns the value associated with the given property.
> >
> > Args:
> >
On 2020-04-10 10:15 a.m., Chris Angelico wrote:
On Fri, Apr 10, 2020 at 8:05 PM Greg Ewing wrote:
>
> On 10/04/20 8:30 am, Soni L. wrote:
> > Sometimes, you have an API:
> >
> > @abc.abstractmethod
> > def get_property_value(self, prop):
> > """Returns the value associated
On Fri, Apr 10, 2020 at 11:35 PM Soni L. wrote:
>
>
>
> On 2020-04-10 10:15 a.m., Chris Angelico wrote:
> > On Fri, Apr 10, 2020 at 8:05 PM Greg Ewing
> > wrote:
> > >
> > > On 10/04/20 8:30 am, Soni L. wrote:
> > > > Sometimes, you have an API:
> > > >
> > > > @abc.abstractmethod
> > > >
On 11/04/20 1:15 am, Chris Angelico wrote:
StopIteration wants to say hello :)
By "rare' I mean as a proportion of APIs in existence. StopIteration
is frequently used, but it's just one API.
The only other one I can think of in the stdlib is EOFError, and
that isn't even used all that much.
On Sat, Apr 11, 2020 at 12:28 AM Greg Ewing wrote:
>
> On 11/04/20 1:15 am, Chris Angelico wrote:
>
> > StopIteration wants to say hello :)
>
> By "rare' I mean as a proportion of APIs in existence. StopIteration
> is frequently used, but it's just one API.
>
> The only other one I can think of in
On 10/04/20 11:43 pm, Soni L. wrote:
it's actually fairly common to deal with KeyError instead of using
dict.get or w/e.
When doing that, though, it's good practice to make sure the
try/except encloses the minimum amount of code needed.
E.g. instead of
try:
value = somedict[get_m
On 11/04/20 12:56 am, Soni L. wrote:
why's a "help us fix bugs related to exception handling" proposal
getting so much pushback? I don't understand.
You're proposing a syntax change, which is a *very* big deal.
It requires a substantial amount of justification.
idk what
else those massive fra
On 2020-04-10 11:39 a.m., Greg Ewing wrote:
On 10/04/20 11:43 pm, Soni L. wrote:
it's actually fairly common to deal with KeyError instead of using
dict.get or w/e.
When doing that, though, it's good practice to make sure the
try/except encloses the minimum amount of code needed.
E.g. inst
A protocol that other Future implementations would be great. The Dask
distributed library has an API compatible with concurrent.futures, but would
never be appropriate for inclusion in the standard library. It'd be perfect if
Dask's Future objects would work well with concurrent.futures.as_compl
On Apr 10, 2020, at 06:00, Soni L. wrote
> why's a "help us fix bugs related to exception handling" proposal getting so
> much pushback? I don't understand.
Because it’s a proposal for a significant change to the language semantics that
includes a change to the syntax, which is a very high bar
On 11/04/20 2:34 am, Chris Angelico wrote:
AttributeError, KeyError/IndexError, and GeneratorExit (and
StopAsyncIteration) want to say hi too.
Okay, there are a few others. But the important thing for our
purposes is that APIs designed specifically to use exceptions
for flow control (such as St
The Python Users list most often asked question seems to be
from Windows users who run the installed multiple times
because they assume that the install is the python program.
Followed by I installed Python, where is it?
My suggestion is that the installer wizard
"Setup was successful" panel has
On Sat, Apr 11, 2020 at 3:31 AM Greg Ewing wrote:
>
> On 11/04/20 2:34 am, Chris Angelico wrote:
> > AttributeError, KeyError/IndexError, and GeneratorExit (and
> > StopAsyncIteration) want to say hi too.
>
> Okay, there are a few others. But the important thing for our
> purposes is that APIs des
On 2020-04-10 2:24 p.m., Andrew Barnert wrote:
On Apr 10, 2020, at 06:00, Soni L. wrote
> why's a "help us fix bugs related to exception handling" proposal getting so
much pushback? I don't understand.
Because it’s a proposal for a significant change to the language semantics that
includes
On Sat, Apr 11, 2020 at 4:35 AM Soni L. wrote:
> in one of my libraries (yes this is real code. all of this is taken from
> stuff I'm deploying.) I have the following piece of code:
>
> def _extract(self, obj):
> try:
> yield (self.key, obj[self.key])
> except (
On 2020-04-10 3:43 p.m., Chris Angelico wrote:
On Sat, Apr 11, 2020 at 4:35 AM Soni L. wrote:
> in one of my libraries (yes this is real code. all of this is taken from
> stuff I'm deploying.) I have the following piece of code:
>
> def _extract(self, obj):
> try:
>
I rarely use Windows, but do support them, so this sounds good to me.
But one confusion:
With py.exe no need to mess with the PATH.
>
How does py.exe get on the PATH?
Now that the need for python 2 and 3 on the same machine is greatly reduced
-- is it so bad to put python.exe on the PATH?
Also
On 2020-04-10 20:14, Christopher Barker wrote:
I rarely use Windows, but do support them, so this sounds good to me.
But one confusion:
With py.exe no need to mess with the PATH.
How does py.exe get on the PATH?
py.exe goes into the Windows folder, which is on the PATH.
Now that the ne
I have an idea to improve the python language through the creation of a new and
very readable function.
#
def ranlen(x):
#range of length of x
return range(len(x))
#
This will be a simple to use and very readable way of creating ranges of
indexes. I hope
range(len(x)) is actually not that important. You probably need to be using
enumerate() more often.
On Fri, Apr 10, 2020 at 9:44 PM Chamoun Saoma wrote:
> I have an idea to improve the python language through the creation of a
> new and very readable function.
>
>
> #
> def ranle
Hello Everyone,
If I've done this incorrectly, please let me know so that I can
improve/revise. I'm new to the Python community and quite enjoy the more
functional features of Python 3, but have I have a peeve about it. I'd like
to propose and discuss the following enhancement to Python 3:
*Consi
On 4/10/20, MRAB wrote:
> On 2020-04-10 20:14, Christopher Barker wrote:
>
>> How does py.exe get on the PATH?
>>
> py.exe goes into the Windows folder, which is on the PATH.
That's the typical setup, but a standard user that can't get OTS
administrator access has to install the launcher just for
On 2020-04-10 5:21 p.m., Elliott Dehnbostel wrote:
Hello Everyone,
If I've done this incorrectly, please let me know so that I can
improve/revise. I'm new to the Python community and quite enjoy the
more functional features of Python 3, but have I have a peeve about
it. I'd like to propose
On Fri, Apr 10, 2020 at 5:26 PM Elliott Dehnbostel
wrote:
> Hello Everyone,
>
> If I've done this incorrectly, please let me know so that I can
> improve/revise. I'm new to the Python community and quite enjoy the more
> functional features of Python 3, but have I have a peeve about it. I'd like
André Roberge wrote:
> On Fri, Apr 10, 2020 at 5:26 PM Elliott Dehnbostel pydehnbos...@gmail.com
> wrote:
> > Hello Everyone,
> > If I've done this incorrectly, please let me know so that I can
> > improve/revise. I'm new to the Python community and quite enjoy the more
> > functional features of P
(meant to reply to the thread here so I'll send it again)
Thanks everyone for the input. I used a trivial example where the inside is
a single, simple expression (which can be refactored in many different,
clever ways) but the idea was that more complicated blocks could not be
(easily) refactored
On Sat, Apr 11, 2020 at 7:06 AM Elliott Dehnbostel
wrote:
>
> (meant to reply to the thread here so I'll send it again)
>
> Thanks everyone for the input. I used a trivial example where the inside is a
> single, simple expression (which can be refactored in many different, clever
> ways) but the
Thanks. How do I go explore the archives?
I think the spirit of this is along the following line:
for(int i = 0; (cond); i++)
...
Is a common way to a express a loop breaking out once a condition is not
met, as is true for:
while cond
But there is no way to express (in terse fashion) a loop in
On Sat, Apr 11, 2020 at 7:41 AM Elliott Dehnbostel
wrote:
>
> Thanks. How do I go explore the archives?
>
They're available from the Mailman page linked in the footer:
https://mail.python.org/mailman3/lists/python-ideas.python.org/
You might have to do some digging, as the words "filter" and "l
10.04.20 23:21, Elliott Dehnbostel пише:
If I've done this incorrectly, please let me know so that I can
improve/revise. I'm new to the Python community and quite enjoy the more
functional features of Python 3, but have I have a peeve about it. I'd
like to propose and discuss the following enha
I am all in for that proposal.
Let the construction:
for element in iterable if condition:
loop_body
mean:
for element in iterable:
if not condition: continue
loop_body
However this construction may be abused (in a good way) to cause the
`condition` be eva
I have implemented a class in the C code of the collections module which
has similar behavior to the defaultdict class. This class, dynamicdict,
supplies values for keys that have not yet been added using a default
factory callable, but unlike defaultdict, the missing key itself is passed
to the c
On Fri, Apr 10, 2020 at 2:56 PM Serhiy Storchaka
wrote:
> Don't listen to anyone. There is only one obvious way to write this in
> one line:
>
> count = +(lambda *a: a[0](*a))((lambda q, r, s, i: r(r, q, s, i, next(i,
> s))), (lambda r, q, s, i, x: x is not s and (x in seek) + q(q, r, s,
> i)), [
I appreciate all your comments and input :-) Since I'm still new-ish to
Python (only a few months, but not new to programming in general) I of
course am not the best source of a strict technical design for such a
feature. I am however wondering how something like this ever "advances"
from a little
On Apr 10, 2020, at 12:46, Chamoun Saoma wrote:
>
> I have an idea to improve the python language through the creation of a new
> and very readable function.
> #
> def ranlen(x):
> #range of length of x
> return range(len(x))
> #
I find this less readable
It's weird, counterintuitive, unclear syntax to do something already
handled much better by simply subclassing exceptions. I reckon that's why
push-back.
On Fri, Apr 10, 2020, 8:59 AM Soni L. wrote:
>
>
> On 2020-04-10 9:40 a.m., Rhodri James wrote:
> > On 10/04/2020 12:43, Soni L. wrote:
> >> i
On Sat, Apr 11, 2020 at 10:11 AM Elliott Dehnbostel
wrote:
>
> I appreciate all your comments and input :-) Since I'm still new-ish to
> Python (only a few months, but not new to programming in general) I of course
> am not the best source of a strict technical design for such a feature. I am
>
On Apr 10, 2020, at 13:29, Elliott Dehnbostel wrote:
>
> We could do this:
> chars = "abcaaabkjzhbjacvb"
> seek = {'a','b','c'}
> count = sum([1 for a in chars if a in seek])
> However, this changes important semantics by creating an entire new list
> before summing.
It sounds like you really ar
On Apr 10, 2020, at 15:53, Steele Farnsworth wrote:
>
> I have implemented a class in the C code of the collections module which has
> similar behavior to the defaultdict class. This class, dynamicdict, supplies
> values for keys that have not yet been added using a default factory
> callable,
On Fri, Apr 10, 2020 at 4:27 PM Elliott Dehnbostel
wrote:
> *Consider the following trivial for-loop:*
>
> chars = "abcaaabkjzhbjacvb"
> seek = {'a','b','c'}
> count = 0for a in chars:
> if a in seek:
> count += 1
>
>
I would definitely not write it that way. Instead I would write
I have often wanted this! I use defaultdict only occasionally, and every
time I do, I start out thinking it behaves the way you describe
dynamicdict. Then I read the docs again and decide I didn't actually want
defaultdict to start with, and roll something different.
On Fri, Apr 10, 2020, 6:50 PM
On Fri, Apr 10, 2020 at 06:02:25PM -0700, Andrew Barnert via Python-ideas wrote:
> (Keep in mind that defaultdict
> was added somewhere around 2.4 or 2.5, while __missing__ has only been
> there since somewhere around 2.7/3.3. I’ll bet it would be different
> if it were invented today.)
Both
On 11/04/20 6:34 am, Soni L. wrote:
def _extract(self, obj):
try:
yield (self.key, obj[self.key])
except (TypeError, IndexError, KeyError):
if not self.skippable:
raise exceptions.ValidationError
You can separate out the TypeErr
On 2020-04-10 11:16 p.m., Greg Ewing wrote:
On 11/04/20 6:34 am, Soni L. wrote:
def _extract(self, obj):
try:
yield (self.key, obj[self.key])
except (TypeError, IndexError, KeyError):
if not self.skippable:
raise exceptions.Val
On Fri, Apr 10, 2020 at 11:20:55PM +0100, haael wrote:
> Let the construction:
>
> for element in iterable if condition:
> loop_body
>
> mean:
>
> for element in iterable:
> if not condition: continue
> loop_body
Fortuntely, it is already possible to write that
- Backwards compatible all the way back to Python 1.5.
What!? It's not so recent as that:
Python 1.0.1 (Jul 15 2016)
Copyright 1991-1994 Stichting Mathematisch Centrum, Amsterdam
>>> stuff = [1, 2, 3]
>>> for element in stuff:
... if element > 2:
... print element
...
3
--
Keeping m
On Sat, Apr 11, 2020 at 12:26 PM Soni L. wrote:
>
>
> They used to say that about Rust.
Rust prides itself on not having exception handling, forcing everyone
to do explicit return value checking. I'm not sure how this factors
into the current discussion, since it forces all these functions to
ret
What you seem to be discussing is not normally known as a loop
invariant.
"Loop invariants" are normally understood to be a form of invariant,
i.e. something that doesn't change, not something which does change from
iteration to iteration. A loop invariant is an assertion about the state
of yo
On Fri, Apr 10, 2020 at 10:43:22PM -0400, David Mertz wrote:
> - Backwards compatible all the way back to Python 1.5.
>
> What!? It's not so recent as that:
>
> Python 1.0.1 (Jul 15 2016)
> Copyright 1991-1994 Stichting Mathematisch Centrum, Amsterdam
> >>> stuff = [1, 2, 3]
> >>> for element in
On 11/04/20 10:20 am, haael wrote:
class InvariantError(AssertionError):
pass
def loop_invariant(condition:bool):
if not condition:
raise InvariantError
return True
for element in iterable if loop_invariant(condition):
loop_body
On Sat, Apr 11, 2020 at 03:19:06PM +1200, Greg Ewing wrote:
> Also it doesn't quite do a complete job, because it
> doesn't check the invariant after the last iteration,
I'm not sure whether loop invariants should be checked at the beginning
of the loop, the end of the loop, or both. Anyone know
On 11/04/20 5:38 pm, Steven D'Aprano wrote:
That is surely okay though. If the loop is never entered at all, by the
principle of vacuous truth the condition inside the loop is true.
No. A loop invariant is something that is true before
entering the loop, and remains true after each iteration.
57 matches
Mail list logo
