Soni L. writes:
> so, for starters, here's everything I'm worried about.
>
> 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.
Give me a better one then.
I need a way for quickly annotating loops with invariants. The problem
with context managers is that it needs indentation change which is
definitely not "quick".
Imagine I wanted to take code from some public repo and add loop
invariants to it. If the diff touche
Hello,
On Sat, 11 Apr 2020 10:24:33 +0100
haael wrote:
> Give me a better one then.
>
> I need a way for quickly annotating loops with invariants. The
> problem with context managers is that it needs indentation change
> which is definitely not "quick".
Did you consider implementing (properly)
> On 10 Apr 2020, at 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?
>
> Now that the need for python 2 and 3 on the same mac
On Sat, Apr 11, 2020 at 10:24:33AM +0100, haael wrote:
> Imagine I wanted to take code from some public repo and add loop
> invariants to it. If the diff touches half of the lines of the code, it
> will never be merged.
You have a social problem: you want to annotate for-loops with some sort
o
On 10/04/2020 20:31, Chamoun Saoma wrote:
This will be a simple to use and very readable way of creating ranges
of indexes. I hope for this to become a new pythogenic way of writing
code, especially because using range(leng(x)) is so essential when
implementing various algorithms.
Since the int
On 2020-04-11 5:40 a.m., Stephen J. Turnbull wrote:
Soni L. writes:
> so, for starters, here's everything I'm worried about.
>
> 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 _extrac
On Sat, Apr 11, 2020 at 9:30 PM Soni L. wrote:
>
> alternatively, they can let their caller
> handle it by having the espace come from the caller.
>
> def bar(espace=None):
> x = foo(espace=espace)
>
> and then the caller is expected to handle it, *if they so choose*.
If a function
On 2020-04-11 8:38 a.m., Chris Angelico wrote:
On Sat, Apr 11, 2020 at 9:30 PM Soni L. wrote:
>
> alternatively, they can let their caller
> handle it by having the espace come from the caller.
>
> def bar(espace=None):
> x = foo(espace=espace)
>
> and then the caller is expected
On 4/11/20, Barry Scott wrote:
>> On 10 Apr 2020, at 20:14, Christopher Barker wrote:
>>
>> Also, if order to get python top level scripts to work, there needs to be
>> a PATH entry for that, too.
>
> Do you mean the #! lines? That is taken care of by py.exe and how it was
> installed.
I think b
tl;dr: I show how the goal of Soni L's exception spaces can be addressed
today, via less intrusive means. (Assuming I understand their proposal,
that is.)
On 4/11/2020 7:49 AM, Soni L. wrote:
On 2020-04-11 8:38 a.m., Chris Angelico wrote:
On Sat, Apr 11, 2020 at 9:30 PM Soni L. wrote:
>
>
On 2020-04-11 10:27 a.m., Eric V. Smith wrote:
tl;dr: I show how the goal of Soni L's exception spaces can be
addressed today, via less intrusive means. (Assuming I understand
their proposal, that is.)
what's the point of having standard types if you're not supposed to use
them because the
Hello,
On Tue, 31 Mar 2020 17:01:19 -0700
Christopher Barker wrote:
[]
> However if we're all wrong, and there would be a demand for such a
> "string builder", then why not write one (could be a wrapper around
> StringIO if you want), and put it on PyPi, or even just for own lib,
> and see how
On 4/11/2020 9:38 AM, Soni L. wrote:
On 2020-04-11 10:27 a.m., Eric V. Smith wrote:
tl;dr: I show how the goal of Soni L's exception spaces can be
addressed today, via less intrusive means. (Assuming I understand
their proposal, that is.)
what's the point of having standard types if you're
Hello,
On Mon, 6 Apr 2020 09:41:46 -0700
Christopher Barker wrote:
> Sorry, this has been sitting in my drafts for a while, and maybe this
> conversation is over. But since I wrote it, I figured I might as well
> post it.
I appreciate it, and it's actually my desired intention to not leave
this
Trim! for the sake of all that is holy, and most of what isn't.
Soni L. writes:
> for starters: operator variants wherever exceptions are used as part of
> API contract, and add a kwarg to functions that explicitly define
> exceptions as part of their API contract.
How do I decide when to (
On Sat, Apr 11, 2020 at 4:21 AM Rhodri James wrote:
> Since the introduction of enumerate() lo! these many moons ago, I find I
> almost never write range(len(x)) as a loop iterable.
>
Out of curiosity, I just grepped about 300k lines of source:
234 - enumerate() in for loops
140 - zip() in for
On 2020-04-11 10:46 a.m., Eric V. Smith wrote:
On 4/11/2020 9:38 AM, Soni L. wrote:
On 2020-04-11 10:27 a.m., Eric V. Smith wrote:
tl;dr: I show how the goal of Soni L's exception spaces can be
addressed today, via less intrusive means. (Assuming I understand
their proposal, that is.)
wh
On Sun, Apr 12, 2020 at 1:37 AM Soni L. wrote:
> in current python, you can't safely handle exceptions, *because* of the
> remote chance of them being raised *by the wrong thing/for the wrong reason*.
>
> rust doesn't have that problem, as it effectively forces you to handle
> exceptions all the
On 2020-04-11 12:52 p.m., Chris Angelico wrote:
On Sun, Apr 12, 2020 at 1:37 AM Soni L. wrote:
> in current python, you can't safely handle exceptions, *because* of the
remote chance of them being raised *by the wrong thing/for the wrong reason*.
>
> rust doesn't have that problem, as it eff
It sounds like you've entirely missed the point of Python exceptions. You
are right that they are a kind of dynamic scope. That's their entire reason
for existing, not a bug.
In Python, we can handle an exception at the particular scope in which it
is most appropriate and useful to handle it, and
On 2020-04-11 1:01 p.m., David Mertz wrote:
It sounds like you've entirely missed the point of Python exceptions.
You are right that they are a kind of dynamic scope. That's their
entire reason for existing, not a bug.
In Python, we can handle an exception at the particular scope in which
i
> On Apr 10, 2020, at 19:46, Chris Angelico wrote:
>
> 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
If I understand correctly, you want a way for distinguishing between
exceptions that were explicitly and intentionally `raise`'ed as part of
an API and exceptions that were unintentionally raised due to bugs. So
for example:
raise ValueError(f'Illegal value for xyz: {xyz}') # part of the API
On 2020-04-11 8:39 p.m., Dominik Vilsmeier wrote:
If I understand correctly, you want a way for distinguishing between
exceptions that were explicitly and intentionally `raise`'ed as part
of an API and exceptions that were unintentionally raised due to bugs.
So for example:
raise Valu
> On Apr 11, 2020, at 06:52, Paul Sokolovsky wrote:
>
>> And a StringBuilder class would be another way.
>
> StringBuilder would be just subset of functionality of StringIO, and
> would be hard to survive Occam's razor. (Mine is sharp to cut it off
> right away.)
I think _this_ is actually the
On Apr 11, 2020, at 08:22, Eric Fahlgren wrote:
>
>> On Sat, Apr 11, 2020 at 4:21 AM Rhodri James wrote:
>> Since the introduction of enumerate() lo! these many moons ago, I find I
>> almost never write range(len(x)) as a loop iterable.
>
> Out of curiosity, I just grepped about 300k lines of
On 12/04/20 3:57 am, Soni L. wrote:
but those are just
mitigations, not proper solutions. they reduce the risk but don't
eliminate it. why shouldn't we eliminate that risk?
The risk could be completely eliminated today if everyone
rewrote their api-exception-raising methods to catch and
rerais
28 matches
Mail list logo
