[Python-ideas] Re: Implementing a 'but' statement in for-iterations

[Henk-Jaap Wagenaar]

I think the more realistic option is to allow "if" in the for statement.
This has been suggested before, you can find it in the archives.

On Mon, 28 Jun 2021, 22:50 Max Shouman,  wrote:

> This is more of a syntactic sugar than an actual new feature, but...
> Exactly, 'but' is the idea: a special keyword to be used in for statements
> to exclude values ​​from the iterable.
>
> E.g., when iterating over a generator:
> >>> for i in range(0, 10) but (2, 8):
> would implicitly create a new generator comprehensively, as in:
> >>> for i in (j for j in range(0, 10) if j not in [2, 8]):
>
> It might not add such a feature to justify the definition of a but_stmt in
> python.gram, but it's fully compliant with Python's philosophy of concise,
> clear and elegant code.
>
> #road to a programming natural language (jk)
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/YI2ILMNQDFKLDLJN4SLRNWEQA3CPGX5U/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HXM445TJARK2WAF6XVTOPXYV2T2LTD2A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: The Pattern Matching Wildcard Is A Bad Idea

[Henk-Jaap Wagenaar]

This was discussed/litigated/holy wars fought over at extreme length, I
suggest you peruse the email archives searching for PEP 622 or 634 and also
this might be a helpful jumping off point:
https://github.com/gvanrossum/patma/issues.

On Wed, 2 Jun 2021 at 04:18, Julia Schmidt 
wrote:

> From https://docs.python.org/3.10/whatsnew/3.10.html:
>
> def http_error(status):
> match status:
> case 400:
> return "Bad request"
> case 404:
> return "Not found"
> case 418:
> return "I'm a teapot"
> case _:
> return "Something's wrong with the Internet"
>
> The wildcard idea looks just wrong and confusing. What if I want to use it
> as a variable and match against it like _ = 504? This is how it should be
> done:
>
> def http_error(status):
> _ = 504
> match status:
> case 400:
> return "Bad request"
> case 404:
> return "Not found"
> case 418:
> return "I'm a teapot"
> case _:
> return "Gateway Timeout"
> else:
> return "Something's wrong with the Internet"
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/EJE2T26LP3JPWK3YHGZVQFRRMOPKOQDL/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6T72HRPQSXMSXNWRZ5DF4NGWDDI35VI2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: symbolic math in Python

[Henk-Jaap Wagenaar]

On Wed, 19 May 2021 at 07:41, Martin Teichmann 
wrote:

> Hi list,
>
> To frame the problem, let us try  to solve the equation x ** 2 == 1/2
> using sympy:
>
> >>> from sympy import Eq, solve, symbols, S
> >>> x = symbols("x")
> >>> solve(Eq(x**2, S(1)/2))
> [-sqrt(2)/2, sqrt(2)/2]
>
> that worked well, but actually we would like to write the last line simply
> as
>
> >>> solve(x**2 == 1/2)
>
> as you might notice, this is fully legal Python syntax. Unfortunately the
> semantics is such that sympy has no way to determine what is actually going
> on, this is why they invented all those helper functions shown above.
>

Numpy override __eq__ liberally to allow this kind of behaviour (though not
root searching, but returning ndarray instead of a boolean for == so things
remain matrices. As a toy example to show that it is definitely possible to
let the x "poison the well":

```
class Symbolic:
def __init__(self, expression):
self.expression = expression

def __pow__(self, power):
return Symbolic(f"{self.expression} ** {power}")

def __eq__(self, other):
return Symbolic(f"{self.expression} == {other}")

def __truediv__(self, other):
return Symbolic(f"{self.expression} / {other}")

def __str__(self):
return self.expression

def __repr__(self):
return f"{self.__class__}({self.expression})"


x = Symbolic("x")
print(x ** 2 == 1 / 2)
print(x ** 2 == Symbolic(1) / 2)
```

Which gives output:

```
x ** 2 == 0.5
x ** 2 == 1 / 2
```

Now, it hasn't done root solving, but it could (or return an object that
could), so to say that "Unfortunately the semantics is such that sympy has
no way to determine what is actually going on" is an unsound foundation for
your idea.


>
> My idea is now to start at the line above, "x = symbols('x')". I propose a
> new syntax, "symbolic x", which tells the parser that x is a symbolic
> variable, and expressions should not be executed, but handed over as such
> to the calling functions.
>

So... what you're suggesting can basically already be done, though as I did
above, might require some additional "poisoning" so that all roots are
poisoned, just like when there was the thread about float literals (e.g. 1F
/ 3 to become Float(1, 3)).
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KZHUXRBT4BV7TRXVGMBMAY6A4WRX2NKE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Allow trailing operators [was: allow initial comma]

[Henk-Jaap Wagenaar]

This is a definite tangent. Trailing commas are great for reducing git
diffs, not making errors when moving things around (missing commas, which
e.g. in strings causes concatenation) but I have often wondered whether the
same could be extended to (some?) logical or arithmetic operators, in
particular:

Currently one has to write a logical expression as (using Django Q objects):
(
   Q(user=user) |
   Q(is_deleted=True)
)

and then removing/adding clauses is difficult, whereas if "trailing
operators" where allowed, there would be no such issue:

(
Q(user=user) |
Q(is_deleted=True) |
)

Just like with trailing commas, the "additional" operator would be ignored.
I guess (technically) it won't have to match the previous operator, it
could just be any operator with no argument after it.

Unlike with trailing comma, I think an operator on its own would not be
allowed (e.g. "(|)" or "|") as it's meaning-as-intended will be context
dependent (e.g. in this example, the correct answer is a Q() object).

I am happy to flesh this out more, but as this discussion was ongoing, I
thought I would throw it out here and see what people think? Are there
potential problems with this e.g. with parsing it?

On Fri, 12 Mar 2021 at 14:28, Paul Bryan  wrote:

> It seems your proposal is intended to address an aesthetic concern. Is
> there a case where using a leading comma would make something
> actually easier or more intuitive to express over the use of trailing comma?
>
> On Fri, 2021-03-12 at 10:34 +, roland.puntaier--- via Python-ideas
> wrote:
>
> I had posted this as https://github.com/python/peps/issues/1867
> The discussion so far is below.
>
> Please make some arguments.
>
> The major point to me is, that the symmetry is broken,
> which leads to extra editing actions, like removing the comma in the first
> line.
> I guess, this was the reason to allow the comma after the last line/entry:
> `[1,2,]`.
> ``[,1,2]`` should also be allowed, too.
>
> The best argument is one that says: less or more effort in this or that
> situation.
> For example, with `[1,2,]`, in line-wise formatting,
> one can do without special action at the last line (removing the comma
> there).
>
> All code from previous versions of Python would still work
> after a `[,1,2]` syntax allowance were introduced.
>
>
>
> =
> rpuntaie wrote:
>
> =
>
> Allow initial comma
> ===
>
> Final comma works:
>
> t = (
>  1,
>  2,
> )
> x = [
>  1,
>  2,
> ]
> y = {
>  1,
>  2,
> }
> z = {
>  1:11,
>  2:22,
> }
> def fun(
>   a,
>   b,
>  ):
>   pass
>
> Initial comma does not work:
>
> t = (
>  , 1
>  , 2
> )
> x = [
>  , 1
>  , 2
> ]
> y = {
>  , 1
>  , 2
>  }
> z = {
>  , 1:11
>  , 2:22
>  }
> def fun(
>  , a
>  , b
>  ):
>   pass
>
>
> To make the syntax symmetric in this regard\
> gives more freedom to format the code.
>
> I occasionally found the restriction an unnecessary nuisance.
>
> Before writing a PEP, I would like to discuss,
>
> -   whether something like that has been proposed already?
> -   what counter-arguments there could be?
>
>
> =
> pxeger wrote:
>
> =
>
> This is not the appropriate place to propose language changes.
> Try the [python-ideas](
> https://mail.python.org/mailman3/lists/python-ideas.python.org/)
> mailing list. However, I don't think you'll get anyone to agree.
>
> What kind of code style are you using where you want to put commas at
> the start of the line? That is totally non-standard
> (see [PEP 8](https://www.python.org/dev/peps/pep-0008)), ugly, and
> confusing.
>
> Arbitrary symmetry is not a good reason for changing the language. We
> don't have a `tnirp` function just for the sake of symmetry with
> `print` because it would be pointless and add extra complication
>
>
>
> =
> rpuntaie wrote:
>
> =
>
> I surely agree, that not ignoring the sequence is essential. Else one
> would loose identifier space and thus information. I would never have
> the idea to make all permutations of `p.r.i.n.t` point to the same
> function. Therefore you just made a bad example.
>
> But the comma is just a separator. Why did they allow to have the
> comma before a closing bracket/parenthesis/brace? Because of symmetry
> between lines, is my guess.
>
> Occasi

[Python-ideas] Re: [Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

[Henk-Jaap Wagenaar]

On Wed, 24 Feb 2021 at 10:18, Antoine Pitrou  wrote:

> On Tue, 23 Feb 2021 20:29:52 -0500
> Jonathan Goble  wrote:
> >
> > I can't speak for distributors or maintainers [1], but I can speak for
> > myself as a user. I run Debian testing (currently bullseye as that is
> > preparing for release) as my daily OS on my personal laptop, used for
> > personal matters and school assignments (I'm a university computer
> > science student in my senior year).
> >
> > I don't use the system Python for anything of my own, whether it's a
> > school assignment or a personal project, precisely because I don't
> > want to risk screwing something up. Rather, I maintain a clone/fork of
> > the official CPython GitHub repo, and periodically build from source
> > and `make altinstall` into `~/.local/`.
>
> For the record, instead of building Python by hand, you could use a
> distribution such as Anaconda or the community-maintained conda-forge.
>
> Regards
>
> Antoine.
>
>
I've been using pyenv (on MacBooks to be fair, not Linux/Debian) and been
quite happy with that, and it basically does what Jonathan does manually:
clone the github repo and build python from scratch.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OZRHP3Q6EZNCPCTEEXLZGOCTGY6B7YFW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Make for/while loops nameable.

[Henk-Jaap Wagenaar]

Just want to say that that is brilliant, and I would have not thought of
that, that's a cool idea! Only annoyance is that it introduces an
indentation, otherwise it'd be perfect!

On Mon, 7 Dec 2020 at 23:30, Daniel Moisset  wrote:

> For the likely rare situation where I'd want to do this rather than
> refactoring into a function, I might try with something like this without
> requiring changes to the language:
>
> from contextlib import contextmanager
>
> @contextmanager
> def breakable():
> class Break(Exception): pass
> def breaker(): raise Break
> try:
> yield breaker
> except Break:
> pass
>
> This allows defining a block that can be "aborted" (which can have a loop
> or any other statement block within); you abort it by calling the resulting
> value of the context manager. An example of use is available at
> https://gist.github.com/dmoisset/55f5916f9f339a143b6f3d155de8706e
>
>
>
>
> On Thu, 3 Dec 2020 at 11:07, Jonatan  wrote:
>
>> Hi, sometimes I do nested loops and I want to break specific loop,
>> outer/inner etc.
>> I need to do an ugly thing with for..else and it's annoying.
>>
>> It'd be nice if we could do so:
>> for i in range(10) as loop_i:
>> for j in range(i, i + 10) as loop_j:
>> if i + j == 9:
>> break loop_i
>> or something like this.
>> Please comment what do you think about this idea.
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/55E2WXH6KLHZ67IFFCXRC7JIN4YB7EVR/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/VY4KQNADJYALC3MHIDGMJFX4DCF5IA4Q/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2URF6BM3QG5YTH57WFWL7C75L6UUNWEA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Bringing the print statement back

[Henk-Jaap Wagenaar]

On Fri, 23 Oct 2020 at 06:35, Random832  wrote:

> Does anyone else remember when xkcd first mentioned python? The main
> selling point it had for it [and the one that was actually literally true,
> vs 'import antigravity' which was a semi-satirical bit about the
> batteries-included philosophy] was 'Hello world is just print "Hello,
> world!"'
>

For reference the XKCD is https://xkcd.com/353/. I think the point of the
XKCD is not the difference between print "Hello World" and print("Hello
World") but all the other clutter normally needed (importing stdio.h in C
and main function comes to mind) and the other batteries included
(anti-gravity as a joke, but more seriously, all the lovely modules the
users can use by default).


>
> Wouldn't it be nice if that were true again, even if the details of how it
> works [and other things like how you print to other files] aren't quite the
> same as they used to be?
>

I disagree as do many in this thread.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EHX4KCSETXSTTGIAGT5PDD26C6ZBXP5L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: 'Infinity' constant in Python

[Henk-Jaap Wagenaar]

I have commented on Steven's comments about alephs below.

It seems to me that this discussion (on having "different" infinities and
allowing/storing arithmetic on them) is dead-on-arrival because:
- the scope of people who would find this useful is very small
- it would change current behaviour
- it would be unusual/a first among (popular) programming languages*
- consistency is basically impossible: as somebody pointed out, if you have
a (Python) function that is 1 / (x ** 2), will the outcome be (1/0)**2 or
just 1/0? (1/0)**2 is the consistent outcome, but would require
implementing zeros with multiplicity...

This would also create problems underlying, because Python floats (I guess)
correspond to the C and CPU floats, so performance and data
structure/storage (have to store additional data beyond a C(PU) float to
deal with infinities and their size, which would be unbounded if you e.g.
allowed exponentials as you would get into things like Cantor Normal Form (
https://en.wikipedia.org/wiki/Ordinal_arithmetic#Cantor_normal_form)).

I honestly think this way lies madness for the floats of a general purpose
programming language.

* of course, somebody has got to be first!

On Sun, 18 Oct 2020 at 23:03, Steven D'Aprano  wrote:

> Oops, I messed up. (Thanks David for pointing that out.)
>
> On Sun, Oct 18, 2020 at 07:45:40PM +1100, Steven D'Aprano wrote:
>
> > Each of these number systems have related, but slightly different,
> > rules. For example, IEEE-754 has a single signed infinity and 2**INF is
> > exactly equal to INF. But in transfinite arithmetic, 2**INF is strictly
> > greater than INF (for every infinity):
> >
> > 2**aleph_0 < aleph_1
> > 2**aleph_1 < aleph_2
> > 2**aleph_2 < aleph_3
>
> I conflated what I was thinking:
>
> # note the change in comparison
> 2**aleph_0 > aleph_0
> 2**aleph_1 > aleph_1
> 2**aleph_2 > aleph_2
> ...


> which I think is correct regardless of your position on the Continuum
> Hypothesis (David, care to comment?),


Yes, due to Cantor's diagonal argument:
https://en.wikipedia.org/wiki/Cantor%27s_diagonal_argument



> with this:
>
> 2**aleph_0 = aleph_1
> 2**aleph_1 = aleph_2
> 2**aleph_2 = aleph_3
> ...
>
> which is only true if the Continuum Hypothesis is true


*generalized* Continuum Hypothesis, and in fact it isn't "only true if
(G)CH" is much stronger, it is in fact the same statement (if your "..."
means "for all ordinals" as GCH (CH is just the first one of those). See
https://en.wikipedia.org/wiki/Continuum_hypothesis#The_generalized_continuum_hypothesis
.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/Z67R35LP7VT5UJA7F7ZTBGHTERK33IEJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: CPP Namespaces For Python

[Henk-Jaap Wagenaar]

I cannot answer for Alperen, but I commonly encounter this when writing
testing code: generally I use the format:

some_module.py
tests/test_some_module.py

where it is expected the filename to test a module is
"test_module_name.py". However, within that, I might want to namespace
based on the class in some_module.py. If you use something like unittest,
classes are natural but if you use pytest it is unnecessary and commonly I
end up with what Alperen has: marking everything as classmethod. What I
have been looking for is a class/mixin/decorator that marks all methods I
add as classmethods.

Why bother marking as class_method? Well, I think it is bad practice where
possible to have unused input in functions, even in testing code. Often I
have made mistakes for example in copy-pasting and it would be caught if
you look at unused variables and such matters.

YMMV, but this, in some form, gets a +1 from me.

On Tue, 6 Oct 2020 at 14:16, Irit Katriel via Python-ideas <
python-ideas@python.org> wrote:

> Hi Alperen,
>
> Why do you need a class at all rather than just a module with some
> functions?
>
> Irit
>
> On Tuesday, October 6, 2020, 01:38:21 PM GMT+1, Alperen Keleş <
> alpkele...@gmail.com> wrote:
>
>
> Hi,
>
> Please pardon me if my idea is not making sense or already exists, I'm
> kind of new to developing in Python but I had this idea today and I wanted
> to share it with you.
>
> I think a class type such as "@functionclass" may be helpful for creating
> functions intended to keep a list of methods in a scope.
>
> At the moment, I achieved this via writing "@classmethod" to all my
> functions but I think such a decorator might help clarify intent for the
> reader and ease the programmers' job.
>
> My regards,
> Alperen
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/5FE6HAYMRR727HWRQXNQU6LWLCKFTBR2/
> Code of Conduct: http://python.org/psf/codeofconduct/
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/YF6TUVHLE6U7DJPM2VCTS2MDK5KI42MK/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IXS725PI22TK43GQOY55UB3DC5JBNF5S/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Minor contributions to PEPs (Was: PEP 637 - support for indexing with keyword arguments)

[Henk-Jaap Wagenaar]

I noticed a sentence that was not completed in PEP 637. Though I have made
(pretty minor) contributions to CPython and some other things, it isn't
entirely clear to me whether it would be appropriate for me to submit an
issue or pull request for this, and what the general policy is?

https://github.com/python/peps/blob/master/CONTRIBUTING.rst does not make
it any clearer to me, I guess it is kinda the Wild West and depends on the
PEP/what the change is? Would it be worth clarifying this?

Secondly, I wasn't 100% sure this make was a rendering mistake or in the
source. Would it be possible/an idea to include a link to the source (like
the Python documentation does)?

[I am sure people will be curious what the mistake was:

>>> a[3]   # returns the fourth element of a

has the comment unfinished. I guess it should say list or something
similar.]

On Wed, 23 Sep 2020 at 21:59, Stefano Borini 
wrote:

> Dear all,
>
> "Support for indexing with keyword arguments" has now been merged with
> the assigned PEP number 637.
>
> For future reference, this email will be added to the Post-History of the
> PEP.
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZLWTL5QXTSFG3ZWWAOXEL3WAQWZZIPCR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: still more use for pathlib.Path ....

[Henk-Jaap Wagenaar]

I have no idea how hard/bad/maintenance heavy this would be, but wouldn't
the easy way be simply to provide another attribute (e.g. __path__) with
what you want and maintain __file__?

I've never used a Path object (directly), I feel like I'm missing out now!

On Fri, 21 Aug 2020 at 02:09, Christopher Barker 
wrote:

> I really like pathlib.
>
> But for a while is was painful to use, 'cause there was som much code that
> still used strings for paths. That was made a lot better when we introduced
> the __fspath__ protocol, and then updated the standard library to use it
> (everywhere?).
>
> But there are still a few that bug me. For instance:
>
> __file__ is a path represented as a string. It's not too big a deal to
> wrap it in Path(), but it still annoys me.
>
> So: would it be entirely too disruptive to replace these kinds of things
> with Path objects?
>
> -CHB
>
>
>
>
>
> --
> Christopher Barker, PhD
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/GIKHETWTXPG5CM54QV5RIHII57HUVMRM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BDM7AXP2IAHY6LCTAKCV5V72DHCEEWAV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add builtin function for min(max())

[Henk-Jaap Wagenaar]

I do not agree clamp should be restricted to numeric values. I would expect
clamp to be agnostic to the specifics of floats/numbers and like sort
expect it to work for any values as long as they compare (using a dunder).
I think having something like min=-math.inf is hence right out in my mind.
If I got this right, the implementation could be as simple as:

def clamp(value, *, min=None, max=None):
  if min is not None and value < min:
return min
  if max is not None and max < value:
return max
  return value

I think the crucial question here is: does the order of the ifs matter and
is that an issue. The only time (barring side effects, values changing in
between calls et cetera) it would make a difference if max < value < min.
Assuming transitivity (can anybody come up with an example of a
non-transitive order where clamping makes sense?) this means max < min and
so you can work around this by disallowing it:

def clamp_safe(value, * min=None, max=None):
  if max < min:
raise SomeException("Something about min < max")
  return clamp(value, min=min, max=max)

What I like about both of these is that they only use "<", just like sort.

Going back to nans, I think that would mean:

clamp(nan, min, max) = nan
clamp(value, nan, max) = clamp(value, None, max) = max(value, max)
clamp(value, min, nan) = clamp(value, min, None) = min(value, min)

On Mon, 6 Jul 2020 at 02:55, Christopher Barker  wrote:

>
> and we can use +inf and -inf for unlimited bounds as well. Yes, they are a
> bit of a pain to write in Python, but we could do:
>
> def clamp(value, min=-math.inf, max=math.inf):
> ...
>
> yes, that would make them optional, rather than required, and therefore
> provide a slight asymmetry between specifying min only or max only, but
> still be handy. to make it more consistent, but maybe more annoying in the
> common case, we could make them keyword only.
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3AXOG34FEMLAWIQQTBH3CZ5J4JL4GJE7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add builtin function for min(max())

[Henk-Jaap Wagenaar]

On Sat, 4 Jul 2020 at 19:58, Christopher Barker  wrote:

> Hmm.
>
>
> Since NaN is neither greater than nor less that anything, it seems the
> only correct answer to any
> Min,max,clamp involving a NaN is NaN.
>
>
Simplifying the signature, in Python we have:

def min(*iterable):
iterator = iter(iterable)
minimum = next(iterable)
for item in iterator:
if item < minimum:
minimum = item
return minimum

Due to this, min(0, float('nan')) == 0 and same for max. I would hence
expect clamp to behave similarly.

As a side note, the documentation actually underspecifies as in these kind
of situations the iterable overall does not have a well-defined "minimum"
(in a mathematical sense it simply does not have one):
- how you look at the list (forward or backwards)
- how you approach the comparison (item < minimum or not(minimum <= item))
change the behaviour:
- max({0}, {0, 2}, {0, 1}, {1}) = {0, 2} v.s. {0, 1} when you reverse the
iterable
- min(0, float('nan')) = 0 v.s. float('nan') when you change the comparison
Should this be clarified/specified in the docs?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DS6TRZDASYQLE43LW4G74LJ3D7XBWWZW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Keyword 'THIS'

[Henk-Jaap Wagenaar]

*available since Python 3.8. Link here:

https://docs.python.org/3/whatsnew/3.8.html

On Mon, 15 Jun 2020 at 16:06, Henk-Jaap Wagenaar 
wrote:

> How about using the Walrus operator/assignment expression, since Python
> 3.8?
>
> if this := [i for i in range(10) if i == 5]:
>   print(this)
>
> Evaluate: [5]
>
> On Mon, 15 Jun 2020 at 16:03, M Bfmv  wrote:
>
>> Hey all. Ever had some list comprehension hell in your code?
>> Me neither *whistles 418 happly*...
>>
>> I was thinking about this idea and while `this` keyword is equalevant to
>> `self` i have to explain myself.
>> English is not my main language, sorry for that :' ) Here is my pseudo
>> code.
>>
>> ```
>> if [i for i in range(10) if i == 11]:
>> print(this)
>>
>> Evaluate: []
>> ```
>>
>> Another one
>> ```
>> if [i for i in range(10) if i == 5]:
>> print(this)
>>
>> Evaluate: [5]
>> ```
>> As I try to show above. It would be neat to make a list comprhension if
>> statement and use those results in the if condition as the `this` parameter
>> Instead of declaring variables like
>>
>> ```
>> a = [i for i in range(10) if i == 5]
>> if a:
>> print(a)
>>
>> Evaluate: [5]
>> ```
>>
>> I hope I explained my idea well enough and hope to see something like
>> this in the future.
>> If anyone has questions on my interpretation please ask.
>>
>>
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/PB7AHBHELBLRFVKRRQL4M3SNWB4RXGNW/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JCKQM3XJZIO5EWV3GMAWM3QDCPTVVMGN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Keyword 'THIS'

[Henk-Jaap Wagenaar]

How about using the Walrus operator/assignment expression, since Python 3.8?

if this := [i for i in range(10) if i == 5]:
  print(this)

Evaluate: [5]

On Mon, 15 Jun 2020 at 16:03, M Bfmv  wrote:

> Hey all. Ever had some list comprehension hell in your code?
> Me neither *whistles 418 happly*...
>
> I was thinking about this idea and while `this` keyword is equalevant to
> `self` i have to explain myself.
> English is not my main language, sorry for that :' ) Here is my pseudo
> code.
>
> ```
> if [i for i in range(10) if i == 11]:
> print(this)
>
> Evaluate: []
> ```
>
> Another one
> ```
> if [i for i in range(10) if i == 5]:
> print(this)
>
> Evaluate: [5]
> ```
> As I try to show above. It would be neat to make a list comprhension if
> statement and use those results in the if condition as the `this` parameter
> Instead of declaring variables like
>
> ```
> a = [i for i in range(10) if i == 5]
> if a:
> print(a)
>
> Evaluate: [5]
> ```
>
> I hope I explained my idea well enough and hope to see something like this
> in the future.
> If anyone has questions on my interpretation please ask.
>
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/PB7AHBHELBLRFVKRRQL4M3SNWB4RXGNW/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XTXYE2Y6ZMUVRXJL4RQVZEYFAMRBTDBQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: str.strip: argument maxstrip

[Henk-Jaap Wagenaar]

On Wed, 20 May 2020 at 11:34, Alex Hall  wrote:

> On Wed, May 20, 2020 at 2:46 AM Cameron Simpson  wrote:
>
>> On 19May2020 15:43, David Mertz  wrote:
>> Reiterating the Python 3.9 suggestion, what about:
>>
>>   salt2 = salt.cutsuffix(('==', '='))
>>
>
> But if the API was there, I agree this would work, not sure what David is
> saying about needing to call twice. On the other hand, this example
> demonstrates well how a tuple is potentially confusing. What happens if you
> call `'abc=='.removesuffix(('=', '=='))`?
>

I assume that was the practical "how to do it now":

foobar.removesuffix('=').removesuffix('=')

would work right now in 3.9 (I think).


> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/R6GIYPOULXBPWU2TO2ZLTNEUMILI5Z2B/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FFRPCZP3RHNCD3SAO3ZM5AH4VJCX5B2E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: str.strip: argument maxstrip

[Henk-Jaap Wagenaar]

David (or somebody else) could you give us some, as real as possible,
examples? This will strengthen the case for it!

I am confident they exist and are pretty plentiful but I myself am coming
up blank thinking about it for a few minutes and documenting them would be
good for discussion.

On Tue, 19 May 2020 at 18:59, David Mertz  wrote:

> I think this would be useful, and doesn't break any backward
> compatibility.  I would have use for it from time to time myself.
>
> On Tue, May 19, 2020 at 9:01 AM computermaster360 . <
> computermaster...@gmail.com> wrote:
>
>> I often find myself in a need of stripping only a specified amount of
>> characters from a string (most commonly a single character). I have been
>> implementing this in an ad-hoc manner, which is quite inelegant:
>>
>> def rstrip1(txt, chars):
>>   if txt is None:
>> return None
>>   elif any(txt.endswith(c) for c in chars):
>> return txt[:-1]
>>   else:
>> return txt
>>
>> I would appreciate if str.split, str.lstrip, str.rsplit functions had a
>> `maxstrip` argument, similar to the `maxsplit` argument of `str.split`,
>> which would specify the maximum count of characters to be removed from the
>> string. In case of `str.split` this maximum would apply to each side of the
>> string separately.
>>
>> Am I the only one who is surprised such functionality is not implemented
>> already??
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/NSUFM4YA6E65ASDPJZPSJWBS2XEDRDFU/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> The dead increasingly dominate and strangle both the living and the
> not-yet born.  Vampiric capital and undead corporate persons abuse
> the lives and control the thoughts of homo faber. Ideas, once born,
> become abortifacients against new conceptions.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/ZRR3MEKM336G3P3744V6JLFFNPWW7A7N/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IN3RMY654FYLF4CI4TLXSNJC445VNHQC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

[Henk-Jaap Wagenaar]

I think only using the first third of the quote makes your argument too
terse Steven.

To include the second part: "There should be one-- and preferably only one"
which implies "It is preferable there is exactly one qualified pilot in the
cockpit", and we arrive (if abbreviated) at what James said.

However, to use the full quote as inspiration: "There must be at least one
qualified pilot in the cockpit and there should not be a tie for seniority"
and it flips again!

Regardless Steven, I don't think it matters (except for setting the record
straight[1]), they are not essential to his proposal? He uses this idea in
his argument to say we should adopt *one* of := and ?=. Firstly, I think
his application there is correct (if you assume at least one would be
adopted, I think only one would be) but secondly I think his email has a
strong air of false dichotomy: Python could well adopt a different solution
or no solution at all and those are perfectly acceptable outcomes and I
would advocate "no solution" as I prefer it over his two proposals.

[1] https://xkcd.com/386/

On Tue, 19 May 2020 at 01:33, Steven D'Aprano  wrote:

> On Mon, May 18, 2020 at 01:06:22PM -, James Lu wrote:
>
> > "There should be one-- and preferably only one --obvious way to do it."
>
> Yes?
>
> "There should be one" does not mean the same thing as "there shouldn't
> be two".
>
> "There should be one qualified pilot in the cockpit of the plane at all
> times during the flight" is not the same as "There should not be two
> qualified pilots in the cockpit".
>
>
>
> --
> Steven
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/IA32WCRDPACLI6R562GDPETV6WQRUBSV/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5BXCVMWNZKW3EAQKPRMBMNF6UD6VSPQY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Henk-Jaap Wagenaar]

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 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 and == and === and <=> as single symbols. It seems like a
> matter of code presentation, not code itself.
>
> well, I'd find it very confusing to not be able to tell visually whether
> my code contains `→` or `->’
> so this really is the last thing I’d want to do, personnally at least
>
>
>
The '→' is not going to come of nowhere, secondly, your IDE will be quite
unhappy when you introduce invalid syntax and it will tell you about it, so
you will able to "tell visually"
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BBBFUJ37APTZ2CQLINGHNBFMJMB3AZW2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Henk-Jaap Wagenaar]

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 <
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 would feel about taking better advantage of
> non-ascii characters when that seems to make sense
>
>
> fyi here’s how both options appear in a markdown-based website
>
>
>
> thanks !
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/AWXLKPUXSWUXEHMI3FCIJUK25IBPQMGT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TICG3HM7HBIKN7S5E6MPFYCVO5NWQSBT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Equality between some of the indexed collections

[Henk-Jaap Wagenaar]

FYI, it does show in my version on gmail and on the mailman version.
<https://mail.python.org/archives/list/python-ideas@python.org/message/WJKNLRIRYT7EFX7ZH2OHXYI772XD5R3J/>

BTW, I think strings do showcase some problems with this idea, .EQ. (as
defined by Steven) is not recursive, which I think will be
unworkable/unhelpful:

((0, 1), (1, 2)) and ([0, 1], [1, 2]) are not equal under the new operator
(or new behaviour of == depending as per the OP) which I think goes
completely against the idea in my book.

If it were (replace x==y with x == y || x .EQ. y with appropriate error
handling), strings would not work as expected (I would say), e.g.:

[["f"], "o", "o"] .EQ. "foo"

because a an element of a string is also a string. Worse though, I guess
any equal length string that are not equal:

"foo" .EQ. "bar"

would crash as it would keep recursing (i.e. string would have to be
special cased).

What I do sometimes use/want (more often for casual coding/debugging, not
real coding) is something that compares two objects created from JSON/can
be made into JSON whether they are the same, sometimes wanting to ignore
certain fields or tell you what the difference is. I do not think that
could ever be an operator, but having a function that can help these kind
of recursive comparisons would be great (I guess pytest uses/has such a
function because it pretty nicely displays differences in sets,
dictionaries and lists which are compared to each others in asserts).

On Fri, 8 May 2020 at 16:23, Alex Hall  wrote:

> On Fri, May 8, 2020 at 5:11 PM Ethan Furman  wrote:
>
>> On 05/08/2020 07:50 AM, Alex Hall wrote:
>> > On Fri, May 8, 2020 at 4:46 PM Henk-Jaap Wagenaar wrote:
>> >> On Fri, 8 May 2020 at 14:16, Steven D'Aprano > <mailto:st...@pearwood.info>> wrote:
>> >>
>> >>> If you have ever written something like any of these:
>> >>>
>> >>>  all(x==y for x,y in zip(a, b))
>> >>
>> >> That looks like a zip call that could do with checking its input or
>> strict=True!
>> >
>> > Steven mentioned that originally:
>> >>
>> >> (Aside: if we go down this track, this could be a justification for
>> >> zip_strict to be a builtin; see the current thread(s) on having a
>> >> version of zip which strictly requires its input to be equal length.)
>> >
>> > But since you probably want these expressions to evaluate to false
>> rather than raise an exception when the lengths are different, a strict zip
>> is not appropriate.
>>
>> But if:
>>
>>  short_sequence == long_sequence[:len(short_sequence)]
>>
>> then you'll get True.
>>
>
> So you'd need to just check the lengths first. That was in Steven's older
> code snippet, which I tried to quote and shows in my sent messages but not
> now. Really hating this email quoting.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/MSTSV76SAASQDW65JPXOUNJP7X6QLJZG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GKYJLX7HJCZR3NZODMZ7BHIOLYXICVJF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Equality between some of the indexed collections

[Henk-Jaap Wagenaar]

On Fri, 8 May 2020 at 14:16, Steven D'Aprano  wrote:

> On Thu, May 07, 2020 at 03:43:23PM +0200, Dominik Vilsmeier wrote:
>
> > >We could define this .EQ. operate as *sequence equality*, defined very
> > >roughly as:
> > >
> > > def .EQ. (a, b):
> > > return len(a) == len(b) and all(x==y for x, y in zip(a, b))
> > >
> > But why do we even need a new operator when this simple function does
> > the job (at least for sized iterables)?
>
> Maybe it doesn't need to be an operator, but operators do have a big
> advantage over functions:
>
> http://neopythonic.blogspot.com/2019/03/why-operators-are-useful.html
>
> On the other hand we only have a limited number of short symbols
> available in ASCII, and using words as operators reduces that benefit.
>
>
> > How common is it to compare two objects where you cannot determine
> > whether one or the other is a tuple or a list already from the
> > surrounding context? In the end these objects must come from somewhere
> > and usually functions declare either list or tuple as their return type.
>
> Never, because we can always determine whether something is a list or
> tuple by inspecting it with type() or isinstance(). But that's missing
> the point! I don't care and don't want to know if it is a tuple or
> list, I only care if it quacks like a sequence of some kind.
>
> The use-case for this is for when you want to compare elements without
> regard to the type of the container they are in. This is a duck-typing
> sequence element-by-element equality test.
>
> If you have ever written something like any of these:
>
> list(a) == list(b)
> tuple(a) == b
> ''.join(chars) == mystring
> all(x==y for x,y in zip(a, b))
>

That looks like a zip call that could do with checking its input or
strict=True!


> then this proposed operator might be just what you need.
>
>
>
> --
> Steven
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/2375P7QI66QZ4VCL7SJRUFU3AXOMVIJZ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XVK4AMGEMFMVIVDCJVNBYI5TIEXJU77Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Equality between some of the indexed collections

[Henk-Jaap Wagenaar]

Why use "." which has clear syntax problems?

This can already be done in current Python (this was linked to in a
previous thread about something else) using a generic solution if you
change the syntax:

https://pypi.org/project/infix/

You could write it as |EQ|, ^EQ^, ... and have it in its own Pypi package.

Not sure what IDEs think of this package, they probably hate it...

On Thu, 7 May 2020 at 10:18, Steven D'Aprano  wrote:

> On Sat, May 02, 2020 at 05:12:58AM -, Ahmed Amr wrote:
>
> > Currently, when comparing a list of items to an array of the same
> > items for equality (==) it returns False, I'm thinking that it would
> > make sense to return True in that context, as we're comparing item
> > values and we have the same way of indexing both collections, so we
> > can compare item values.
>
> I'm going to throw out a wild idea (actually not that wild :-) that I'm
> sure people will hate for reasons I shall mention afterwards.
>
> Perhaps we ought to add a second "equals" operator? To avoid
> bikeshedding over syntax, I'm initially going to use the ancient 1960s
> Fortran syntax and spell it `.EQ.`.
>
> (For the avoidance of doubt, I know that syntax will not work in Python
> because it will be ambiguous. That's why I picked it -- it's syntax that
> we can all agree won't work, so we can concentrate on the semantics not
> the spelling.)
>
> We could define this .EQ. operate as *sequence equality*, defined very
> roughly as:
>
> def .EQ. (a, b):
> return len(a) == len(b) and all(x==y for x, y in zip(a, b))
>
> (Aside: if we go down this track, this could be a justification for
> zip_strict to be a builtin; see the current thread(s) on having a
> version of zip which strictly requires its input to be equal length.)
>
> The precise details of the operator are not yet clear to me, for
> instance, should it support iterators or just Sized iterables? But at
> the very least, it would support the original request:
>
> [1, 2, 3] .EQ. (1, 2, 3)
> # returns True
>
>
> The obvious operator for this would be `===` but of course that will
> lead to an immediate and visceral reaction "Argghhh, no, Javascript, do
> not want!!!" :-)
>
> Another obvious operator would be a new keyword `eq` but that would
> break any code using that as a variable.
>
> But apart from the minor inconveniences that:
>
> - I don't know what this should do in detail, only vaguely;
> - and I have no idea what syntax it should have
>
> what do people think of this idea?
>
>
> --
> Steven
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/JP3BXZLQRQYHGSB4KOX2K5TLP6A6PLR2/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LVVAQQYY7SYM7M5MGER5DVRVQ2NTMH3O/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Equality between some of the indexed collections

[Henk-Jaap Wagenaar]

TL;DR: the maths does not matter. Programming language (design)/computer
science/data structures should lead this discussion! Also, -1 on this
proposal, -1000 on having it apply to strings.

Feel free to read on if you want to hear some ramblings of somebody who
does not get to use their academic knowledge of maths enough seeing an
opportunity...

On Wed, 6 May 2020 at 07:18, Steven D'Aprano  wrote:

> On Wed, May 06, 2020 at 02:58:01AM +0100, Henk-Jaap Wagenaar wrote:
>
> > I don't think that is accurate to represent as a representation of "a
> > mathematician". The top voted answer here disagrees:
> >
> https://math.stackexchange.com/questions/122595/whats-the-difference-between-tuples-and-sequences
> >
> > "A sequence requires each element to be of the same type.
> > A tuple can have elements with different types."
>
> Are you saying that you can't have a sequence that alternates between
> ints and rationals, say, or ints and surds (reals)?
>
> The sequence A_n = sqrt(n) from n=0 starts off int, int, real, ... so
> there is that.
>

That's a sequence in the reals (or algebraics or some other set that
contains square roots), of which a subsequence also happens to live in the
integers. A square is still a rectangle.


> For what its worth, Wolfram Mathworld disagrees with both Greg's comment
> and the stackexchange answer, stating that a tuple is just a synonym for
> a list, and that both lists and sequences are ordered sets:
>
> https://mathworld.wolfram.com/n-Tuple.html
>
> https://mathworld.wolfram.com/List.html


These two above pertain to data structures in computer science, not
mathematics. An "ordered set" is not a mathematical term I have every come
across, but if it is, it means exactly as how they define a sequence
(though you would have to extend it to infinite sequences to allow infinite
ordered sets):


>
> https://mathworld.wolfram.com/Sequence.html
>
>
>
The notation ([image: a_1], [image: a_2], ..., [image: a_n])  is the same
as saying it is a sequence in some set X^n (if not given an X, setting X =
{a_1, ..., a_n} works, is that cheating? Yes. Is that a problem in
set-theoretic mathematics? Not in this case anyway)


> > The common usage for both is: you have a tuple of (Z, +) representing the
> > Abelian group of addition (+) on the integers (Z), whereas you have the
> > sequence {1/n}_{n \in N} converging to 0 in the space Q^N (rational
> > infinite sequences) for example.
>
> One can come up with many other usages. I think a far more common use
> for tuples are the ordered pairs used for coordinates:
>
> (1, 2)
>

I would call that an ordered pair, or, a sequence of length 2.


>
> So although tuples are ordered sets, and sequences are ordered sets, the
> way they are used is very different. One would not call the coordinate
> (1, 2) a sequence 1 followed by 2, and one would not normally consider a
> sequence such as [0, 2, 4, 6, 8, ...] to be a tuple.
>

I would not use the word "tuple", in my experience, tuple in mathematics
(not computer science!) is only used in the way I described it: to gather
up the information about a structure into one object, so that we can say it
exists: because existing means some kind of set exists, and so we need to
somehow codify for e.g. addition on the integers both the addition and the
integers, i.e. combining two wholly different things into one 2-sequence:
(Z, +). Note that such structures might require infinite tuples, e.g. if
they support infinitely many operators. Anyway, this is where the
StackOverflow answer comes from: tuples are used in parlance for sequences
are in the same "space" for their coordinates, sequences for things that
have all coordinates in the same "space".


> In normal use, a tuple is considered to be an atomic[1] object (e.g. a
> point in space), while a sequence is, in a sense, a kind of iterative
> process that has been reified.
>
>
You can construct a sequence (or tuple) iteratively, but whether you do or
not has no bearing on the end result. Also, tuples are very much not atomic
in the mathematical sense. I would also like to note when you say "a tuple
is considered to be an atomic[1] object (e.g. a point in space)", then to a
mathematician, A_n = 1/sqrt(n) for n = 0, 1, ... is simply a point in space
too: just the space of sequences over the reals.

Mathematicians (generally, in the field of foundational logic it is a tad
different) don't tend to be concerned with differences such as how you
define an object (just need to make sure it exists), whether things are
finite or infinite, specified or unspecified. Unfortunately, in real life,
in a programming language, we do have to care about these things.


>
> > I'd say the diffe

[Python-ideas] Re: Equality between some of the indexed collections

[Henk-Jaap Wagenaar]

On Wed, 6 May 2020 at 01:41, Greg Ewing  wrote:

> On 6/05/20 2:22 am, jdve...@gmail.com wrote:
> > However, if sets and frozensets are "are considered to be
> > fundamentally the same kind of thing differentiated by mutability",
> > as you said, why not tuples and lists?
>
> I think that can be answered by looking at the mathematical
> heritage of the types involved:
>
> Python Mathematics
> -- ---
> setset
> frozenset  set
> tuple  tuple
> list   sequence


>

> To a mathematician, however, tuples and sequences are very
> different things. Python treating tuples as sequences is a
> "practicality beats purity" kind of thing, not to be expected
> from a mathematical point of view.
>
>
I don't think that is accurate to represent as a representation of "a
mathematician". The top voted answer here disagrees:
https://math.stackexchange.com/questions/122595/whats-the-difference-between-tuples-and-sequences

"A sequence requires each element to be of the same type.
A tuple can have elements with different types."

The common usage for both is: you have a tuple of (Z, +) representing the
Abelian group of addition (+) on the integers (Z), whereas you have the
sequence {1/n}_{n \in N} converging to 0 in the space Q^N (rational
infinite sequences) for example.

I'd say the difference is just one of semantics and as a mathematician I
would consider tuples and sequences as "isomorphic", in fact, the
set-theoretical construction of tuples as functions is *identical* to the
usual definition of sequences: i.e. they are just two interpretations of
the the same object depending on your point of view.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/A7JO3MWPYGU2OJHVMC2B55CT6UTKLQBJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: zip(x, y, z, strict=True)

[Henk-Jaap Wagenaar]

On Tue, 5 May 2020, 18:24 Steven D'Aprano,  wrote:

> On Tue, May 05, 2020 at 05:26:02PM +0100, Henk-Jaap Wagenaar wrote:
>
> > This is a straw man in regards to backwards compatibility. This
> particular
> > (sub)thread is about whether if this zip-is-strict either as a separate
> > name or a Boolean flag or some other flag of zip should be a built-in or
> be
> > in e.g. itertools.
>
> Please don't misuse "strawman" in that fashion. A strawman argument is a
> logical fallacy where you attack a weaker position your opponent didn't
> make in order to make your own position stronger. That's not what Chris
> did, and frankly accusing him of strawmanning is a form of "poisoning
> the well".


> What Chris did was to propose a counterfactual to express his opinion on
> this proposal. To paraphrase:
>
> "If this were true (we were designing zip from scratch for the first
> time) then I would agree with the proposal, but since we aren't, I
> disagree because of these reasons."
>
> That is a perfectly legitimate position to take.
>

I agree on the face of it (in regards to strawmanning and your
paraphrasing), except I wasn't disagreeing with anything you've gone into
the detail above, but I disagreed with one of the reasons listed and
thought it was strawmanning, namely the "the backward compatibility break
large" (see further down, why).


>
> "If we weren't in lockdown, I would take you out for dinner at a
> restaurant, but since we are in quarantine, I don't think we
> should go out."
>
> Personally, I don't think Chris' backwards-compatibility argument is
> strong. Technically adding a new keyword argument to a function is
> backwards-incompatible, but we normally exclude that sort of change. Who
> writes this?
>
> # This behaviour will be changed by the proposed new parameter.
> zip('', strict=1)  # Raise a type error.
>
> So I think the *backwards incompatibility* argument is weak in that
> regard. But maybe Chris has got a different perspective on this that I
> haven't thought of.
>
>
I cannot interpret that as a "large" break as Chris says, so I must assume
he meant something else (changing the default is my assumption) unless
somebody (Chris or otherwise) can tell me why adding a keyword argument
would be a large incompatible change?


>
> [Chris]
> > > Should they? I'm not sure how well-supported this actually is. If you
> > > hand-craft an AST and then compile it, is it supposed to catch every
> > > possible malformation?
>
> I would expect that the ast library should accept anything which could
> come from legal Python, and nothing that doesn't.
>
>
> --
> Steven
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/GQZLWLOHFPBQLADHYLHW6JYY2X4S4ABA/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/R4EV4JWACQDCSGBMBXWQSNYTNAJWU6LH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: zip(x, y, z, strict=True)

[Henk-Jaap Wagenaar]

But you care about your input, you can do so by setting strict=True (if
that's the road we go down), and unlike what others have said, the IDE I
use (pycharm) would tell me that flag exists as I type "zip" and so I'd be
more likely to use it than if it was in itertools/...

On Tue, 5 May 2020, 16:41 Rhodri James,  wrote:

> On 05/05/2020 13:53, Henk-Jaap Wagenaar wrote:
> > Brandt's example with ast in the stdlib I think is a pretty good example
> of
> > this.
> >
> > On Tue, 5 May 2020 at 13:27, Rhodri James  wrote:
> >
> >> On 05/05/2020 13:12, Henk-Jaap Wagenaar wrote:
> >>> A function that is a "safer" version in some "edge case" (not extra
> >>> functionality but better error handling basically) but that does
> >> otherwise
> >>> work as expected is not something one will search for automatically.
> This
> >>> is zip versus zip-with-strict-true.
> >>
> >> I'm sorry, I don't buy it.  This isn't an edge case, it's all about
> >> whether you care about what your input is.  In that sense, it's exactly
> >> like the relationship between zip and zip_longest.
>
> Interesting, because I'd call it a counterexample to your point.  The
> bug's authors should have cared about their input, but didn't.
>
> --
> Rhodri James *-* Kynesim Ltd
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IBSSGPEVGBDAQFKDEIDSAEPT26YBYMRP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: zip(x, y, z, strict=True)

[Henk-Jaap Wagenaar]

This is a straw man in regards to backwards compatibility. This particular
(sub)thread is about whether if this zip-is-strict either as a separate
name or a Boolean flag or some other flag of zip should be a built-in or be
in e.g. itertools.

It is not about breaking backwards compatibility (presumably by making it
the default behaviour of zip).

On Tue, 5 May 2020, 17:17 Chris Angelico,  wrote:

> On Wed, May 6, 2020 at 1:44 AM Rhodri James  wrote:
> >
> > On 05/05/2020 13:53, Henk-Jaap Wagenaar wrote:
> > > Brandt's example with ast in the stdlib I think is a pretty good
> example of
> > > this.
> > >
> > > On Tue, 5 May 2020 at 13:27, Rhodri James 
> wrote:
> > >
> > >> On 05/05/2020 13:12, Henk-Jaap Wagenaar wrote:
> > >>> A function that is a "safer" version in some "edge case" (not extra
> > >>> functionality but better error handling basically) but that does
> > >> otherwise
> > >>> work as expected is not something one will search for automatically.
> This
> > >>> is zip versus zip-with-strict-true.
> > >>
> > >> I'm sorry, I don't buy it.  This isn't an edge case, it's all about
> > >> whether you care about what your input is.  In that sense, it's
> exactly
> > >> like the relationship between zip and zip_longest.
> >
> > Interesting, because I'd call it a counterexample to your point.  The
> > bug's authors should have cared about their input, but didn't.
> >
>
> Should they? I'm not sure how well-supported this actually is. If you
> hand-craft an AST and then compile it, is it supposed to catch every
> possible malformation? Has Python ever made any promises about
> *anything* regarding manual creation of AST nodes? Maybe it would be
> *nice* if it noticed the bug for you, but if you're messing around
> with this sort of thing, it's not that unreasonable to expect you to
> get your inputs right.
>
> If you're creating a language from scratch and want to have separate
> "strict" and "truncating" forms of zip, then by all means, go ahead.
> But I think the advantage here is marginal and the backward
> compatibility break large.
>
> ChrisA
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/3JKQREPI4CE2ZEB75URDQMGKEWHJEJVO/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CZX6FMFGUAPXZYKJL3C6L2P3YOSGBAAA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: zip(x, y, z, strict=True)

[Henk-Jaap Wagenaar]

Brandt's example with ast in the stdlib I think is a pretty good example of
this.

On Tue, 5 May 2020 at 13:27, Rhodri James  wrote:

> On 05/05/2020 13:12, Henk-Jaap Wagenaar wrote:
> > A function that is a "safer" version in some "edge case" (not extra
> > functionality but better error handling basically) but that does
> otherwise
> > work as expected is not something one will search for automatically. This
> > is zip versus zip-with-strict-true.
>
> I'm sorry, I don't buy it.  This isn't an edge case, it's all about
> whether you care about what your input is.  In that sense, it's exactly
> like the relationship between zip and zip_longest.
>
> --
> Rhodri James *-* Kynesim Ltd
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/U47NZNW5DIZLW34UTNEFYQ3ZCRW57EMU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TVK7DRO4LNEAH3PAB5IJB5DI6TOBJ3TJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: zip(x, y, z, strict=True)

[Henk-Jaap Wagenaar]

I feel like that argument is flawed. I cannot think of another good example
(I am sure there are plenty!) but there is a big difference for
discoverability between:

A function that does something *different* and functionality does not exist
in a built-in (or whatever namespace you are considering). For example,
zip_longest v.s. zip: if you have know/expect one of your iterators to run
out early, but do not wish the zipping to end, normal zip won't do and so
you will end up searching for an alternative.

A function that is a "safer" version in some "edge case" (not extra
functionality but better error handling basically) but that does otherwise
work as expected is not something one will search for automatically. This
is zip versus zip-with-strict-true.

I did not phrase that particularly well, but I am hoping people get the
gist/can rephrase it better.

On Tue, 5 May 2020 at 11:34, Paul Moore  wrote:

> On Tue, 5 May 2020 at 07:22, Christopher Barker 
> wrote:
>
> > In any case, you seem to making the argument that a few of us are
> putting forward: yes, a flag on zip() is likely to get more use than a
> function in itertools. Thanks for the support :-)
>
> I'd like to add my voice to the people saying that if someone isn't
> willing to go and find the correct function, and import it from the
> correct module, to implement the behaviour that they want, then I have
> no interest in making it easier for them to write their code
> correctly, because they seem to have very little interest in
> correctness. Can someone come up with any sort of credible argument
> that someone who's trying to write their code correctly would be in
> any way inconvenienced by having to get the functionality from
> itertools?
>
> It seems like we're trying to design a way for people to
> "accidentally" write correct code without trying to, and without
> understanding what could go wrong if they use the current zip
> function. I'm OK with "make it easy to do the right thing", but "make
> it easy to do the right thing by accident" is a step too far IMO.
>
> Paul
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/E3C4GFR6XVFJFOPTKQX4VI647HHBJVYC/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZFEBTPTOX4TMI42OGBSVQ37AMP3ZFFJQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Auto-assign attributes from __init__ arguments

[Henk-Jaap Wagenaar]

You are not the first to have this idea. Unless I am mistaken you might
find what you are looking for in dataclasses which were added in Python 3.7:

https://docs.python.org/3/library/dataclasses.html

On Mon, 4 May 2020 at 19:06, Lewis Ball  wrote:

> Hi All,
>
> First of all, if this is something which has been discussed in the past
> the please point me in the right direction.
>
> *Problem:*
>
> When creating classes in Python, I find myself writing the __init__ method
> in a very similar way a lot of the time, that is:
> ```
> def __init__(self, argument_1, argument_2, argument_3=None):
> self.argument_1 = argument_1
> self.argument_2 = argument_2
> self.argument_3 = argument_3
> # then maybe some other attribute setting and logic follows
> ```
>
> Every argument of __init__ gets a corresponding attribute with the same
> name. This means that each `argument_i` has been typed 3 times, which seems
> overly-verbose as well as being easy to mistype. This pattern is easy to
> find in various popular python libraries, and in some it is actually
> enforced. For example, I do quite a bit of work with classifiers using the
> sklearn estimator API, and for various reasons sklearn enforce this pattern
> for an __init__ (see here
> 
> if interested).
>
> Here is an example of this pattern from the standard library (from
> textwrap.TextWrapper):
> ```
> def __init__(self,
>  width=70,
>  initial_indent="",
>  subsequent_indent="",
>  expand_tabs=True,
>  replace_whitespace=True,
>  fix_sentence_endings=False,
>  break_long_words=True,
>  drop_whitespace=True,
>  break_on_hyphens=True,
>  tabsize=8,
>  *,
>  max_lines=None,
>  placeholder=' [...]'):
> self.width = width
> self.initial_indent = initial_indent
> self.subsequent_indent = subsequent_indent
> self.expand_tabs = expand_tabs
> self.replace_whitespace = replace_whitespace
> self.fix_sentence_endings = fix_sentence_endings
> self.break_long_words = break_long_words
> self.drop_whitespace = drop_whitespace
> self.break_on_hyphens = break_on_hyphens
> self.tabsize = tabsize
> self.max_lines = max_lines
> self.placeholder = placeholder
> ```
>
> With a quick scan of the top 50 or so most used python packages, *1 in 4*
> __init__ methods that takes arguments has the line `self.argument_i =
> argument_i` for every single argument, with several of them having 10+
> arguments.
>
> *Suggestion:*
>
> A new built-in called something like `assign()` which would assign every
> single __init__ arg to a corresponding attribute. e.g. the snippet from
> above could be rewritten to:
> ```
> def __init__(self, argument_1, argument_2, argument_3=None):
> assign()
> # other init logic goes here
> ```
>
> This could alternatively be implemented as a decorator, like so
> ```
> @assign
> def __init__(self, argument_1, argument_2, argument_3=None):
> # other init logic goes here
> ```
> but then this requires a `pass` if no other logic is needed inside the
> __init__. There may also be some other syntax for this which would be even
> easier to use.
>
> Is this something that others would find useful?
>
> Thanks,
>
> Lewis
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/VLI3DOFA5VWMGJMJGRDC7JZTRKEPPZNU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6O7NA2QVZ7IHDS3PWAZZF56OVGFTRBRN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Henk-Jaap Wagenaar]

Of course, there are other ways of writing this code, but imagine this for
a database interface where a save normally returns the saved object
(inspired by Django)

```
try:
x, y = Foo.save()
except ValueUnpackingError:
// oh... this means saving failed (it returned None instead)
// let's return a sensible response
return ExceptionToResponse(FooStateToException(foo.state))
```

Another example would be an interactive session where you expect an
iterable to have 3 entries (say for a 3D space coordinate) and you want to
check this specifically:

```
try:
x, y, z = point
except ValueUnpackingError:
print(f"point has wrong dimension")
```

where point is an instance of:

```
class Point:
def __iter__(self):
return (float(x) for x in self._internal)
```

Can you spot here why ValueError would result in significantly different
behaviour? ValueError will also catch it if point's internal list contains
a bad entry (e.g. a string that does not convert to a float).

Having these exceptions does not take anything away as they can choose the
more general version.

On Sat, 2 May 2020 at 11:12, Eric V. Smith  wrote:

> On 5/2/2020 6:00 AM, Henk-Jaap Wagenaar wrote:
>
> On Fri, 1 May 2020 at 10:29, Steven D'Aprano  wrote:
> [...]
> > "Is it UnpackingOverflowException or PackingUnderflowError or
> > TooManyValuesUnpackException or ValueUnpackingError or ...???"
>
> > It took me far too long to learn the difference between
> > UnicodeEncodingError and UnicodeDecodingError. Or is it
> > UnicodeEncodeError and UnicodeDecodeError?
> >
> > It is possible to have too many fine-grained errors as well as too
> few.
>
> This is thinking about exceptions and the proposal too simply. When I read
> this, I (a) found out that this exception is a built-in so it isn't hard to
> find out which is which (any IDE or IPython would help) but more
> importantly, looking at their MRO, if you cannot understand the difference,
> and you don't have to, you could instead choose to catch UnicodeError
> instead (or the combination of both).
>
> However, if you just want to catch encoding errors you can, and this is
> the crux of this proposal: allowing similar catches throughout the standard
> library as a first class citizen seems sensible to me and I am +1 of this
> proposal.
>
> Please show an example of where you would catch ValueUnpackingError and
> how you'd handle it (recover, re-raise, whatever).
>
> Eric
>
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/I26BBAZY7HP2XFH32FW3WKVPXEAEA6JY/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FKHQVRGQFSMZTLZA4NGD2CNZGWQULE7R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Henk-Jaap Wagenaar]

On Fri, 1 May 2020 at 10:29, Steven D'Aprano  wrote:
[...]
> "Is it UnpackingOverflowException or PackingUnderflowError or
> TooManyValuesUnpackException or ValueUnpackingError or ...???"

> It took me far too long to learn the difference between
> UnicodeEncodingError and UnicodeDecodingError. Or is it
> UnicodeEncodeError and UnicodeDecodeError?
>
> It is possible to have too many fine-grained errors as well as too
few.

This is thinking about exceptions and the proposal too simply. When I read
this, I (a) found out that this exception is a built-in so it isn't hard to
find out which is which (any IDE or IPython would help) but more
importantly, looking at their MRO, if you cannot understand the difference,
and you don't have to, you could instead choose to catch UnicodeError
instead (or the combination of both).

However, if you just want to catch encoding errors you can, and this is the
crux of this proposal: allowing similar catches throughout the standard
library as a first class citizen seems sensible to me and I am +1 of this
proposal.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CGFGNYT3RO64HPCJGZXVVLF2MMK33CGR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optimize out unused variables

[Henk-Jaap Wagenaar]

I like the idea of formalizing "unused variables".

How about having a syntax for it? Allowing a "." instead of an
identifier to signify this behaviour [reusing Serhiy's examples]:

head, ., rest = path.partition('/')
first, second, *. = line.split()
for . in range(10): ...
[k for k, . in pairs]

Potentially for unpacking one could use nothing, e.g.

first, second, * = line.split()

I don't think "." is necessarily a good symbol for it, but I think the
grammar would cope.

On Wed, 8 Apr 2020 at 22:56, Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:

> On Apr 8, 2020, at 10:59, Serhiy Storchaka  wrote:
> >
> > I doubted whether or not to write, but since Guido has already touched
> a similar topic (see "Live variable analysis -> earlier release"), so will
> I write.
> >
> > It is common to assign some values which are never used to variables
> because the syntax demands this. For example:
> >
> >head, _, rest = path.partition('/')
> >first, second, *_ = line.split()
> >for _ in range(10): ...
> >[k for k, _ in pairs]
> >
> > What if make such assignments no-op? It will only work with some
> limitations:
> >
> > 1. The variable is local. Not global, not nonlocal, not cell.
> > 2. The variable name must start with '_'. Otherwise there would be
> larger risk of breaking a legal code which uses locals() with str.format()
> or like.
> > 3. "del" is considered a use of the variable. So explicitly deleted
> variables will not be optimized out.
> > 4. Star-assignment still consumes the iterator. It just might not to
> keep all values in memory.
> >
> > STORE_FAST will be replaced with POP_TOP in these cases.
>
> Could you go so far as to remove the variable from the locals if its only
> assignment(s) are optimized out? I’m not sure how much benefit that would
> provide. (Surely it would sometimes mean an f_locals array fits into one
> cache line instead of two, or that a whole code object stays around in L2
> cache for the next time it’s called instead of being ejected, but often
> enough to make a difference? Maybe not…)
>
> > I wrote some code few weeks ago, and it is not too complex. My doubts
> are only that the benefit of the optimization with the above limitations is
> very restricted.
>
> Like Guido’s idea, this seems like something that should definitely be
> safe enough as an opt-in decorator or whatever, and implementable that way.
> And that also seems like the best way to answer those doubts. Write or find
> some code that you think should benefit, add the decorator, benchmark, and
> see.
>
> Also, with an opt-in mechanism, you could relax the restrictions. For
> example, by default @killunused only kills unused assignments that meet
> your restrictions, but if I know it’s safe I can @killunused("_”, “dummy”)
> and it kills unused assignments to those names even if it wouldn’t normally
> do so. Then you could see if there are any cases where it’s useful, but
> only with the restrictions relaxed, and maybe use that as a guide to
> whether it’s worth finding a way to aim for looser restrictions in the
> first place or not.
>
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/UVKV7VH3GTC3IU5L6W6F2GD3XVZRLHMO/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/B52WJS53AFJHDRBRB55NG226BTTGMNSV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Improving Traceback for Certain Errors by Expanding Source Displayed

[Henk-Jaap Wagenaar]

Dear Ideas,

TL;DR include multiple lines in traceback when appropriate (expressions
broken up over multiple lines) to make it easier to spot error from looking
at traceback

Apologies if this has been suggested/discussed before. I am suggesting that
if you do:

```
[
x for x in 0
]
```

the traceback will be:

```
Traceback (most recent call last):
  File "foo.py", line 1-3, in 
[
x for x in 0
]
TypeError: 'int' object is not iterable
```

instead of the current

```
Traceback (most recent call last):
  File "foo.py", line 1, in 
[
TypeError: 'int' object is not iterable
```

Similarly for when an operator is applied over different lines:

```
(
   0 &
   "world"
)
```

would lead to
```
Traceback (most recent call last):
  File "foo.py", line 2-3, in 
0 &
"world"
TypeError: unsupported operand type(s) for &: 'int' and 'str'
```

instead of

```
Traceback (most recent call last):
  File "foo.py", line 2-3, in 
"hello" &
TypeError: unsupported operand type(s) for &: 'int' and 'str'
```

Or when an open has been split over multiple lines (note missing comma):

```
open(
"foo"
"r"
)
```

to be

```
Traceback (most recent call last):
  File "foo.py", line 1-4, in 
open(
"foo"
"r"
)
FileNotFoundError: [Errno 2] No such file or directory: 'foor'
```

instead of

```
Traceback (most recent call last):
  File "foo.py", line 1-3, in 
open(
FileNotFoundError: [Errno 2] No such file or directory: 'foor'
```

I don't think this change would rock the world, but I think it is a nice
quality-of-life improvement that would ease debugging. In particular the
last example (open function call) showcases how it can make easier to spot
a bug, especially if it is to do with how the expression is broken up

What do people think? Any particular reason this is not possible or done?
I'm guessing it would require quite a bit of restructuring in the traceback
object/module and potentially have backwards compatibility implications.

All the best,

Henk-Jaap
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SKA4JZGYOSRJVCHH6Y2CA2MDIX3MMPZA/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] if in for-loop statement

[Henk-Jaap Wagenaar]

I think, in that particular example, that is an ok solution, however if you
are combining multiple booleans to create a lambda or separate function
that is quite a bit of syntactical sugar to add (unless it is re-used).

H-J

On 23 February 2017 at 18:11, Régis Martin  wrote:

> Hello,
> why not using the filter function?
>
> for x in filter(is_prime, range(100)):
> # do something with x
>
> This is equivalent as was mentionned at first:
>
> for x in range(100) if is_prime(x):
> # do things with x
>
> Régis
>
> --
> Régis  Martin
> Directeur de Projets Astek Industrie
> Tel: 06-83-53-15-05
> http://www.groupeastek.com/
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] if in for-loop statement

[Henk-Jaap Wagenaar]

Hi Paul,

Thanks for typing that all out and taking the time to respond to my emails.
I think as you say, it might be good to put this somewhere obvious.

I did find https://docs.python.org/devguide/langchanges.html and
http://www.curiousefficiency.org/posts/2011/02/justifying-python-language-changes.html
but the things you wrote would be useful to add the former (or be linked
from there). It would also be good if there was a counter-point to that
blog post of changes (like this one) that are not sufficiently thought
through or significant enough to be accepted: it is always good to have
examples on both sides.

In terms of your "it keeps coming up", maybe there should be a general PEP
(or something else) that simply outlines a bunch of ideas (and will be kept
adding to) that keep cropping up but have been rejected/received
unsympathetically many times? Including maybe links to these threads?

Maybe that is something that could save you (and others subscribed) time
and effort?

H-J

On 23 February 2017 at 15:02, Paul Moore  wrote:

> On 23 February 2017 at 14:20, Henk-Jaap Wagenaar
>  wrote:
> >
> > In a straw poll at the company I work at everyone was in favour, though
> they
> > obviously are not in charge of implementing or changing documentation so
> > that is easy for them to say, they've got no skin in the game. I don't
> know
> > whether it is common for such an idea to be brought up again and again by
> > newcomers/those who don't strolls the archives enough, but if it keeps
> being
> > brought up, and the main argument against is it would take time and
> effort
> > to document and implement for little benefit, if Python sticks around
> for a
> > long enough time, it will end up taking less time simply implement it!
>
> We really need a FAQ for this, if there isn't one already. You quoted
> Nick referring to a post I'd already made on this, and while I'm
> afraid I don't have time to find a link for you, I'll try to summarise
> again here.
>
> The bar for syntax changes to Python (and also library changes,
> although to a slightly lesser extent) is deliberately very high. This
> is not because people don't like proposals, but rather because the
> proposers consistently and drastically underestimate the cost of
> adding new features to the language.
>
> Things that need to be factored into the cost of a change:
>
> 1. Written materials, such as books, training courses, blog posts will
> be out of date, at best offering obsolete advice, at worst being
> outright wrong. Either the authors have extra work to do to change
> them, or the readers need to learn the "new truth", probably by making
> mistakes that they could have avoided if the material were correct.
> 2. Core developers need to understand the implementation of the new
> feature in order to support it.
> 3. Unintended consequences and/or problems with the design of the new
> feature (= bugs) need to be fixed.
> 4. People writing code that needs to support multiple versions of
> Python probably won't benefit, as they'll have to avoid the feature.
> But they will pay costs:
>   a) They need to review that decision over time - is the new feature
> compelling enough that we should drop support for older versions yet?
>   b) If there's an existing way of writing the construct, why ever
> change to the new version at all?
>   c) PRs written by people used to the new feature will need reviewing
> and fixing for compatibility.
> 5. People not interested in the new feature will encounter it in other
> people's code and will need to understand it.
> 6. Someone has to code it. It's often not at all clear whether the
> proposer is offering to spend the time implementing the feature, and
> we typically don't bluntly say "well, will you write the code?" both
> because it's a bit aggressive, and also because an answer of "yes"
> isn't enough by itself - so we don't want to mislead people that the
> *only* problem is finding someone to code the change.
>
> There's probably others that I have missed.
>
> In addition, there's a couple of other points, not directly related to
> cost but still downsides of new features:
>
> 1. People need to be able to search for the new feature and learn it.
> For syntax in particular, that's hard, as you can't search for
> something unless you know the right terms. Often a library function is
> better than syntax for precisely this reason.
> 2. If a new syntax is defined as "equivalent to XXX which is how you
> write it now", then (a) it immediately violates the "there should be
> one obvious way to do it" rule, *unless* the n

Re: [Python-ideas] if in for-loop statement

[Henk-Jaap Wagenaar]

One does not seem to be able to do this in a generator expression:

foo = (x for x in [1, 2] if True else [1, 2, 3])

gives a syntax error, however, adding parenthesis 'solves' this:

foo = (x for x in [1, 2] if True else [1, 2, 3])

In the for-loop version, either works. Though I guess this would be even
more frowned upon, one can even do:

for x in [], print("Here be dragons"):
pass

Whether it can be implemented in an LL(1) parser, my gut says it could, but
this does complicate matters if one were to continue supporting it and
create a whirl of confusion.

If anything, this shows that there could have been scope for more
consistency between the for-statement and generator expression by enforcing
parenthesis in the for-loop as well but I think the grammar as it is will
be here to stay, unless there is going to be a Python 4 like there is
Python 3...

I think to be honest this is a pretty big nail in the coffin.

H-J



On 23 February 2017 at 14:51, Jelle Zijlstra 
wrote:

> 2017-02-23 5:37 GMT-08:00 Henk-Jaap Wagenaar :
> >
> > Hi all,
> >
> > Often I have typed something like
> >
> > for x in range(100) if is_prime(x):
> > # do things with x
> >
> > to find that this does not work, instead resorting to:
> >
> > for x in range(100):
> > if is_prime(x):
> > # do things with x
> >
> > or
> >
> > for x in range(100):
> > if not is_prime(x):
> > continue
> > # do things with x
> >
> > Other solutions to another case of this 'problem' are discussed has been
> discussed on StackOverflow (http://stackoverflow.com/
> questions/6981717/pythonic-way-to-combine-for-loop-and-if-statement)
> where it is suggested one uses a generator expression before the loop. None
> of these solutions seem very Pythonic to me.
> >
> > I appreciate there is a cost associated with changing the language
> syntax, and I do not understand all the finer details of the inner workings
> involved with the Python language development, however in my limited
> understanding in it would be:
> > - fully backwards compatible,
> > - require one to change "expression_list" to "or_test [comp_iter]" in
> the syntax of the for statement (if I got it right).
> > - it would mean there is a Pythonic solution to a current 'problem' that
> does not have one.
> >
> > A few problems I foresee:
> > - One wants for loops to bleed their target_list (that is the point
> normally), so this is different from generators,
> > - This allows for nesting of generators, like in a generator expression
> which might be hard to implement?
> >
> I think it might also be difficult to parse. Python currently supports
> this syntax:
>
> In [8]: for x in [1, 2] if True else [1, 2, 3]:
>...: print(x)
>...:
> 1
> 2
>
> I'm not sure the parser could distinguish this structure from the one
> you propose (which would have a very different meaning) without making
> it significantly more complicated. Changes that make the parser more
> complicated than LL(1) have been consistently rejected in the past;
> see https://www.python.org/dev/peps/pep-3099/.
>
> >
> > Note that this has been suggested before at least once (
> https://mail.python.org/pipermail/python-dev/2007-November/075257.html),
> and that thread itself suggests it has been suggested before and shutdown
> by Guido (though no source is given for this).
> >
> > All the best,
> >
> > Henk-Jaap Wagenaar
> >
> > ___
> > Python-ideas mailing list
> > Python-ideas@python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] if in for-loop statement

[Henk-Jaap Wagenaar]

Hi Paul, Daniel, others,

That is fair enough and the right amount of blunt.

Let me go through the points that were made in that thread (I have not
found any other threads, if someone links to them, I will go through them
as well):

-

From: https://mail.python.org/pipermail/python-dev/2007-November/075258.html,
alternative solution (in current language):

> for x in (x for x in range if is_prime(x)):
> # do something with x

This statement seems overly complicated for what it is trying to achieve
and is semantically much harder to parse than the proposed alternative,
e.g. there is repetition of the string "for x in".



A similar point to where I started from in https://mail.python.org/piperm
ail/python-ideas/2016-September/042600.html:

>"Sorry to re-raise this thread--I'm inclined to agree that the case
>doesn't really warrant new syntax.  I just wanted to add that I think
>the very fact that this syntax is supported by list comprehensions is
>an argument *in its favor*.
>
>I could easily see a Python newbie being confused that they can write
>"for x in y if z" inside a list comprehension, but not in a bare
>for-statement.  Sure they'd learn quickly enough that the filtering
>syntax is unique to list comprehensions.  But to anyone who doesn't
>know the historical progression of the Python language that would seem
>highly arbitrary and incongruous I would think.
>
>Just $0.02 USD from a pedagogical perspective.
>
>Erik"



The thread Daniel mentioned was ended by the following post
https://mail.python.org/pipermail/python-ideas/2016-September/042285.html

>Generally speaking, we only add new syntax in cases where we're
>prepared to say "In all cases where the new syntax applies, it should
>be used in preference to existing alternative spellings".
>
>Special casing a single "if-continue" in a loop body doesn't meet that
>(deliberately high) bar, with Paul Moore's email going into some more
>detail on the specifics of that.
>
>Cheers,
>Nick."

I am not sure I agree with what he is saying (or I am not following it...).
I think no-one in that thread particularly demonstrated why this could not
supersede all equivalent solutions, even if the if is longer (but not
complex), one can simply do:

for x in range(10) \
 if is_prime(x) and is_overabundant(x) and is_perfect(x) and x != 5:
# do something with x

where you would line up the if with the range/... on the previous line
(this example is silly, because the conditions cannot be satisfied). This
in my view would still be clearer and more concise than the alternative
solutions.

The emails in the threads seem to indicate that almost everyone is a shade
of grey here, where some really like it (but can life without), some think
it is alright but don't particularly mind, and some think it is not the
worth the cost or would allow abuse. No-one seems to fundamentally hate the
idea, or in a alternative world where it was already in Python, would
suggest taking it out (even if it a backwards-incompatible epoch like 2->3
was approaching) though my reading between the lines of emails can be
wrong. I think Erik's email (see above) shows this most clearly.

In a straw poll at the company I work at everyone was in favour, though
they obviously are not in charge of implementing or changing documentation
so that is easy for them to say, they've got no skin in the game. I don't
know whether it is common for such an idea to be brought up again and again
by newcomers/those who don't strolls the archives enough, but if it keeps
being brought up, and the main argument against is it would take time and
effort to document and implement for little benefit, if Python sticks
around for a long enough time, it will end up taking less time simply
implement it!

Best,
Henk-Jaap

On 23 February 2017 at 13:54, Daniel Moisset 
wrote:

> Just as a reference, I think the most recent reincarnation of this thread
> was: https://mail.python.org/pipermail/python-ideas/2016-Sep
> tember/042270.html
>
> On 23 February 2017 at 13:46, Paul Moore  wrote:
>
>> On 23 February 2017 at 13:37, Henk-Jaap Wagenaar
>>  wrote:
>> > Note that this has been suggested before at least once
>> > (https://mail.python.org/pipermail/python-dev/2007-November/075257.html
>> ),
>> > and that thread itself suggests it has been suggested before and
>> shutdown by
>> > Guido (though no source is given for this).
>>
>> Thanks for your interest, but as you note this has already been
>> proposed and rejected (from my personal recollection, more than once).
>>
>> So the key question is surely, what are you proposing that wasn't
>> already discussed in previous threads, and why 

[Python-ideas] if in for-loop statement

[Henk-Jaap Wagenaar]

Hi all,

Often I have typed something like

for x in range(100) if is_prime(x):
# do things with x

to find that this does not work, instead resorting to:

for x in range(100):
if is_prime(x):
# do things with x

or

for x in range(100):
if not is_prime(x):
continue
# do things with x

Other solutions to another case of this 'problem' are discussed has been
discussed on StackOverflow (
http://stackoverflow.com/questions/6981717/pythonic-way-to-combine-for-loop-and-if-statement)
where it is suggested one uses a generator expression before the loop. None
of these solutions seem very Pythonic to me.

I appreciate there is a cost associated with changing the language syntax,
and I do not understand all the finer details of the inner workings
involved with the Python language development, however in my limited
understanding in it would be:
- fully backwards compatible,
- require one to change "expression_list" to "or_test [comp_iter]" in the
syntax of the for statement (if I got it right).
- it would mean there is a Pythonic solution to a current 'problem' that
does not have one.

A few problems I foresee:
- One wants for loops to bleed their target_list (that is the point
normally), so this is different from generators,
- This allows for nesting of generators, like in a generator expression
which might be hard to implement?

Note that this has been suggested before at least once (
https://mail.python.org/pipermail/python-dev/2007-November/075257.html),
and that thread itself suggests it has been suggested before and shutdown
by Guido (though no source is given for this).

All the best,

Henk-Jaap Wagenaar
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/