Re: [Python-ideas] Exception for developer errors?
You have AssertionError for that. Elazar בתאריך יום ה׳, 11 באפר׳ 2019, 1:10, מאת Stefano Borini < stefano.bor...@gmail.com>: > I occasionally found situations where I want to raise an exception for > errors that can only arise because the developer made a mistake, for > example: > > - an abstract method is supposed to be reimplemented and its execution > is supposed to leave some internal constraints of an object unchanged, > but these are instead violated. > - an impossible "else" condition after an if/elif, where the else > cannot simply happen unless someone really screwed up the internal > state of the object. > > In general, when these cases happen, I use RuntimeError, but other > people may choose otherwise. I've also seen ValueError, plain > Exception or a specifically made subclass used in these cases. > Whatever the choice is, it generally lacks clarity of communication to > whoever receives it. > RuntimeError is a rather generic exception according to the > documentation, and you can only rely on the message, which relies on > writing something appropriate for the situation: > > ``` > exception RuntimeError > Raised when an error is detected that doesn’t fall in any of the other > categories. The associated value is a string indicating what precisely > went wrong. > ``` > > while it would be useful to communicate clearly to whoever is using or > modifying the code "listen, it's your mistake, you misunderstood how I > work or you ruined my internals, leading me to an impossible state". > Also, customers seeing this kind of exception would understand without > a doubt that the application is broken because of an internal error. > > I tried some search on the mailing list but could not find anything at > a glance about this topic. Was this already discussed in the past? > > Thanks > > -- > Kind regards, > > Stefano Borini > ___ > 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] Why operators are useful
בתאריך יום ג׳, 19 במרץ 2019, 0:41, מאת Greg Ewing < greg.ew...@canterbury.ac.nz>: > Rémi Lapeyre wrote: > > > You can make "inferences from the way things are used". But the > > comparison with maths stops here, you don’t make such inferences because > your > > object must be well defined before you start using it. > > In maths texts it's very common to see things like 'Let y = f(x)...' > where it's been made clear beforehand (either explicitly or implicitly) > what type f returns. > > That's completely analogous to inferring the type bound to a Python > name from an assignment statement. > > > You can track types with > > comments but you need to comment each line. > > No, you don't, because most lines in most programs allow types to > be inferred. The reason that things like MyPy are possible and > useful is that Python programs in practice are usually well-typed. > > > In maths, an given object is not duck because it quacks and walks like > > a duck, it’s > > either part of the set of all ducks, or not. > > But there's no restriction on how you define the set of all ducks. > It could be "the set of all things that quack". Duck typing is > totally possible in mathematics, even common. > > For example, in linear algebra the ducks are "anything you can > apply a linear operator to". That can cover a surprisingly large > variety of things. > > > But the equation is only meaningful in a given context. Asking whether > > f: x -> 1/x > > is differentiable is only meaningful if we know whether x is in R, C, > > [1; +oo[... > > That depends on what you want to say. You can say "let f be a > differentiable function" and then go on to talk about things that > depend only on the differentiability of f, without knowing > exactly what types f operates on. Then later you can substitute > any function you know to be differentiable, and all of those > thing will be true for it. > > Mathematicians abstract things this way all the time. Groups, > fields, vector spaces, etc. are all very abstract concepts, > defined only as a set of objects having certain properties. > If that's not duck typing, I don't know what is. > Technically, that's structural typing. Duck typing is only relevant when there is some kind of control flow, and things need not always have all the properties in question. But I don't think this difference is that important in the context. Elazar ___ 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] AMEND PEP-8 TO DISCOURAGE ALL CAPS
בתאריך שבת, 5 בינו׳ 2019, 2:10, מאת Abe Dillon > The whole point of the all-caps globals is to tell you a lot about what >> they are. > > A lot? The only thing it canonically tells you is to not modify it > Wrong. It also tells it's unlikely to be modified by the code that does declare it, which can really help when reaaoning about the code, or debugging it, as it makes many potential sources of bugs less likely. Elazar ___ 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] Possible PEP regarding the use of the continue keyword in try/except blocks
I think the main issue is this: exception handling is already problematic with its nonlocal transfer of control. Making it bidirectional makes code even more difficult to understand. State will change "under your feet" without any syntactic clue. In "The Design and Evolution of C++" Bjarne Stroustroup quotes an engineer working on a large system using such a feature extensively ; they ended up having to rewrite every single occurrence of it because it introduced a huge amounts of bugs. This is the reason C++ does not support resume semantics. Newer languages go in the direction of avoiding exceptions altogether, not adding more intricate control flow directives. This proposal is basically about introducing goto to the language. Elazar בתאריך יום ב׳, 7 בינו׳ 2019, 5:07, מאת Richard Damon < rich...@damon-family.org>: > On 1/6/19 9:54 PM, simon.bordeyne wrote: > > I knew that you can just chain try/except blocks, and it's how I do it > > now, but the example I provided wasn't very realistic. > > > > Take for example the initialization of a class from a config file, > > config file which may or may not have certain keys in it. With many > > keys, it is very inconvenient to chain try/except blocks to handle > > every possible case. Having the continue keyword would prove useful to > > put several error prone lines of code into a single try block, and > > have the execution continue as normal at tge statement after the > > statement errored out > > > > > For something like reading options from a config file, I would use a > call that specifies the key and a value to use if the key isn't present, > and inside that function I might use a try to handle any exception > caused when processing the key, and it could return the default. > > For your case, it is hard to imagine what you could put in the except > block to handle the error, as you have no idea which key threw the > error, so you have no idea which key needs to be fixed. > > Also, what happens if the exception is thrown inside a function that is > called, do you return to the next line of that function, or the next > line after the function call? > > What happens if the exception happens inside a loop (that is inside the > try)? Do you just go to the next instruction in the loop and continue > looping? > > -- > Richard Damon > > ___ > 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] TypeHinting: From variable name to type
Related: https://github.com/python/mypy/issues/2103 - Elazar On Fri, Oct 19, 2018 at 2:15 PM Anders Hovmöller wrote: > > > > On 19 Oct 2018, at 12:15, Steven D'Aprano wrote: > > > > On Fri, Oct 19, 2018 at 09:18:02AM +0200, Thomas Güttler wrote: > > > >> Imaging you are developing in the django context. > >> > >> Everytime you use a variable named "request" or "response" your human > brains > >> knows that this is a subclass of django.http.HttpRequest and > >> django.http.HttpResponse. > > > > Not *my* human brain. > > > > I've seen far too many variables called (let's say) "mylist" which > > actually hold a dict or a tuple (or in one memorable case, a string!) to > > unconditionally believe the name. > > This is an even stronger argument for the proposal I think. If IDEs and > static analysis tools looked at stuff like this and assumed a type _and > then found that this assumption is violated_, it would be a huge win! > > >> How to give the IDE this knowledge? > >> > >> One solution is the do typehinting everywhere the veriable gets used. > > > > You shouldn't need to. Your IDE or type-checker should be able to do > > type-inference and infer the type. You only need to add a hint if it > > cannot infer the type. > > > > If your IDE doesn't do type inference, get a better IDE *wink* > > > Which IDE would this be? PyCharm doesn't do this in the general case. Not > even close in the code base I work on. > > > >> And this mapping dict exists once per library. > > > > Or more likely, doesn't exist at all. > > You seem to argue here, and generally, that the normal case for code bases > is that you have no consistent naming. This seems strange to me. Can I ask > what type of code and how big code bases you work on? To me it seems we > have radically different perspectives, and we'll continue talking past each > other if we don't explain those perspectives to each other. > > I'll go first: I work on a code base that: > - is ~240k dry lines > - is ~15 years old > - it a web app with just one production install > - has very good consistent naming, for example: > - the "request" example above exists over 6000 times in the code base > and all of them are HttpRequestBase-derived (or in a few cases a mock that > pretends to be that). > - the word "party" exists over 11 thousand times, all of them are an > instance of the Party django model > > Being able to tell PyCharm to assume the type of these and flag obvious > violations would be great. > > > >> If you are developing in the requests http lib, then > >> there is a different mapping. Then "response" means > >> type requests.Response. > > > > What if you are using *both* django and requests in the same module? You > > could have both of these: > > > >response = something_returning_requests_Response() > > > >response = something_returning_django_HttpResponse() > > > > in the one module. > > Then you'd use the normal typing annotations to override the default. > > > / Anders > ___ > 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] Simplicity of C (was why is design-by-contracts not widely)
On Sun, Sep 30, 2018, 15:12 Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Steven D'Aprano writes: > > > (4) Inheritance > > > > Contracts are inherited, unit tests are not. > > What does "inherited" mean? Just that methods that are not overridden > retain their contracts? > Contracts are attached to interfaces, not to specifications. So when you have abstract base class, it defines contracts, and implementing classes must adhere to these contracts - the can only strengthen it, not weaken it. This way the user code need pnly be aware of the specification, not the implementation. So method that _are_ overridden retain their contracts. This is precisely like with types, since types are contracts (and vice versa, in a way). Elazar ___ 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] CoC violation
On Fri, Sep 21, 2018, 16:56 Philipp A. wrote: > The main clause differentiating bad, weaponizable CoCs from good ones is > > "Assume good faith" > > Everything will be OK if good faith can reasonably be assumed (E.g. when > someone uses a word which is only offensive based on context) > On the other hand, e.g. obvious racial slurs never have a place on a > discussion board about a programming language. How can one possibly say > them in good faith? > Here's how: as a demonstration that words that are considered slurs in certain contexts (such as the word "Negro" in America) might be considered perfectly legitimate day-to-day words in another context. Even if the example was incorrect, it is still legitimate. Your question should be directed against the OP in the discussion, bringing up an issue completely unrelated to programming languages (probably trolling, as several people before me have pointed out). Elazar > Rhodri James schrieb am Fr., 21. Sep. 2018 um > 15:46 Uhr: > >> On 20/09/18 19:56, Brett Cannon wrote: >> > Based on the WG's recommendation and after discussing it with Titus, the >> > decision has been made to ban Jacco from python-ideas. Trivializing >> > assault, using the n-word, and making inappropriate comments about >> > someone's mental stability are all uncalled for and entirely >> unnecessary to >> > carry on a reasonable discourse of conversation that remains welcoming >> to >> > others. >> >> Not a challenge to the ban in any way, but I feel the need to repeat >> what I said about banning words. The moment you create that taboo, you >> give the word power. That's the exact opposite of what you want to do. >> It's the intent with which the word is used that matters. I've heard >> all sorts of words used as insults -- "special", anyone? -- and many of >> the same words used innocently or affectionately. >> >> Banning bad or insulting behaviour is fine. Banning words is a bad path >> to go down. >> >> -- >> Rhodri James *-* Kynesim Ltd >> ___ >> 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/ > ___ 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] A simple proposal concerning lambda
I don't think this change makes sense, but if it's done, there should be another change, with actual implications: There is no way to express the types of the parameters in a lambda - `lambda x: int : x` is obviously a syntax error. Replacing the colon with a different symbol, such as "=>" will make this possible: def x => x def x: int => x def x: int -> int => x It will also give one less meaning to the colon. Elazar On Tue, Aug 21, 2018 at 6:28 PM MRAB wrote: > On 2018-08-22 01:25, Jonathan Fine wrote: > > Hi Abe > > > > Summary: You've done good work here. I've skim read the 2006 > > discussion you found. > > > > You wrote: > > > >> I'm trying to dig up past threads about alternatives to lambda because I > >> would be astonished if "def" hadn't been considered and rejected for > some > >> reason. What I've found so far is this unreassuring post from Guido > back in > >> 2006 > > > >> [Python-Dev] Let's just *keep* lambda > >> https://mail.python.org/pipermail/python-dev/2006-February/060415.html > > > > This is an excellent piece of work. I'm most grateful. Here's what Guido > said: > > > >> After so many attempts to come up with an alternative for lambda, > >> perhaps we should admit defeat. I've not had the time to follow the > >> most recent rounds, but I propose that we keep lambda, so as to stop > >> wasting everybody's talent and time on an impossible quest. > > > > I've quickly read through the posts that followed Guido's message, > > picked out the ones that interest me. Here's a list. > > > >> https://mail.python.org/pipermail/python-dev/2006-February/060487.html > >> https://mail.python.org/pipermail/python-dev/2006-February/060474.html > >> https://mail.python.org/pipermail/python-dev/2006-February/060471.html > >> https://mail.python.org/pipermail/python-dev/2006-February/060445.html > >> https://mail.python.org/pipermail/python-dev/2006-February/060435.html > >> https://mail.python.org/pipermail/python-dev/2006-February/060431.html > >> https://mail.python.org/pipermail/python-dev/2006-February/060470.html > > > > And one of the messages had a link to still live and excellent page > > > >> https://wiki.python.org/moin/AlternateLambdaSyntax > > > > This page lists over 100 suggestions, mostly variants. So far as I can > > see, my simple proposal isn't listed on that page. The page also says > > > Hmm. > > That lists: > > def (a, b, c): return f(a) + o(b) - o(c) > > and: > > def (a, b, c) = f(a) + o(b) - o(c) > > but not: > > def (a, b, c): f(a) + o(b) - o(c) > > >> **Definitely Desirable Features** > > [snip] > >> *More friendly to inexperienced users* > > [snip] > >> Compared to other Python keywords, 'lambda' is rather esoteric. > >> In the challenge for "farthest outside day-to-day English usage", > >> its closest competitor would probably be 'assert', as even 'def' > >> and 'elif' are just abbreviations for 'define' and 'else if'. Use of > >> simpler keywords may make deferred expressions appear less > >> intimidating than they seem with the current unusual keyword. > > > > The word 'deferred' appears 7 times on the page. It also appears in > > the python-dev messages. > > > > If someone with more time and less bias then myself were to summarise > > this discussion from 2006, I'd be most grateful, and they'd have > > material for a great blog post. > > > > Finally, many thanks to Abe for finding this gem, and countless > > people's hard work in keeping it alive to be found. Backwards > > compatibility is there for a reason. > > > ___ > 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] Pre-conditions and post-conditions
You might also be interested in pep-563 <https://www.python.org/dev/peps/pep-0563/>. although it is not intended for design by contract, it can help (syntactically). Elazar On Wed, Aug 15, 2018 at 11:07 PM Marko Ristin-Kaufmann < marko.ris...@gmail.com> wrote: > Hi, > > I would be very interested to bring design-by-contract into python 3. I > find design-by-contract particularly interesting and indispensable for > larger projects and automatic generation of unit tests. > > I looked at some of the packages found on pypi and also we rolled our own > solution (https://github.com/Parquery/icontract/). I also looked into > https://www.python.org/dev/peps/pep-0316/. > > However, all the current solutions seem quite clunky to me. The decorators > involve an unnecessary computational overhead and the implementation of > icontract became quite tricky once we wanted to get the default values of > the decorated function. > > Could somebody update me on the state of the discussion on this matter? > > I'm very grateful for any feedback on this! > ___ > 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] Jump to function as an an alternative to call function
I have no opinion on the proposal, but the equation with goto is dead wrong. Yes, technically this is a goto. But so is a regular function call. Jumping to a function makes thd code _easier_ to reason about, statically, not harder. When you call an arbitrary function, you have no idea whether it will return or not. When you jump to a function, you _know_ it will not return. That's strictly more information, based solely on the syntax of the statement. Yes, if you have local functions mutating the state then jumpung to them makes the code difficult to read. *but so is calling them*, with the addition of the returning that you have to track. Jumping to functions is procedural programming. There is no reasonfor it to be "considered harmful" any more than calling funcions; indeed even less so. Elazar On Wed, Aug 15, 2018, 17:42 Eric Fahlgren wrote: > How about just > https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf > > On Wed, Aug 15, 2018 at 5:38 PM David Mertz wrote: > >> Hmm.. link broke. Is this right? >> >> >> https://www.google.com/url?sa=t=web=j=https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf=2ahUKEwi8lqHYqfDcAhXImOAKHeAzDmsQFjAEegQIBhAB=AOvVaw1CZug_36-PbevItYXTb7SR >> >> On Wed, Aug 15, 2018, 8:35 PM David Mertz wrote: >> >>> Goto considered harmful. >>> >>> >>> https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf=2ahUKEwi8lqHYqfDcAhXImOAKHeAzDmsQFjAEegQIBhAB=AOvVaw1CZug_36-PbevItYXTb7SR >>> >>> On Wed, Aug 15, 2018, 3:52 PM Jacob Solinsky >>> wrote: >>> >>>> -Jumping to a function as opposed to calling a function >>>> >>>> When a function is jumped to, it inherits the variables in the caller’s >>>> local namespace and is free to modify them or add new local variables, >>>> unlike a normal function call, wherein the caller’s namespace is >>>> inaccesible. At present, the only way I know of to accomplish this is to >>>> bundle all variables in the caller method’s namespace as properties of the >>>> method’s instance and have the callee method modify those properties. >>>> Though it is easier to read code written this way, it resulted in a great >>>> deal of redundancy in the code I was writing. The task I was attempting to >>>> accomplish was approximately this: >>>> >>>> class Verb: >>>> def __init__(self, parameters): >>>> self.parameters = parameters >>>> def conjugate(self): >>>> #Using the parameters, chose an appropriate list of >>>> morphemes to prefix and suffix to the verb >>>> self.morphemelist = morphemelist >>>> for morpheme in self.morphemelist: >>>> morpheme.mutate() >>>> returnstring = ‘' >>>> for morpheme in self.morphemelist: >>>> returnstring = returnstring + morpheme.form >>>> returnstring = returnstring >>>> >>>> class Morpheme: >>>> def __init__(self, verb, form, precedingmorpheme, >>>> succeedingmorpheme): >>>> self.verb = verb >>>> self.form = form >>>> self.precedingmorpheme = precedingmorpheme >>>> self.succeedingmorpheme = succeedingmorpheme >>>> def mutate(self): >>>> #Using the verb’s parameters and the type and form of >>>> the preceding and succeeding morpheme, mutate this morpheme’s form so that >>>> #a correct verb form is produced >>>> self.form = newform >>>> >>>> class Ban(Morpheme): >>>> def __init__(self, verb, form): >>>> super().__init__(verb, ‘ban’) >>>> def mutate(self): >>>> #This morpheme has mutation logic unique to itself but >>>> with many similarities to the default morpheme’s mutation logic >>>> self.form = newform >>>> >>>> Each subclass of Morpheme has its own slightly different mutate method. >>>> Some subclasses of Morpheme needed to access and manipulate a great deal of >>>> information about the verb and their surroundings, while other subclasses’ >>>> mutate methods differed little from the default. Most of the variables >>>> manipulated by the mutate method are not used by any other meth
Re: [Python-ideas] Make "yield" inside a with statement a SyntaxError
On Tue, Aug 7, 2018 at 11:16 PM Ken Hilton wrote:
> ...
> Now, let's take a look at the following scenario:
>
> def read_multiple(*filenames):
> for filename in filenames:
> with open(filename) as f:
> yield f.read()
>
> Can you spot the problem? The "with open(filename)" statement is supposed
> to ensure that the file object is disposed of properly. However, the "yield
> f.read()" statement suspends execution within the with block, so if this
> happened:
>
> for contents in read_multiple('chunk1', 'chunk2', 'chunk3'):
> if contents == 'hello':
> break
>
> and the contents of "chunk2" were "hello" then the loop would exit, and
> "chunk2" would never be closed! Yielding inside a with block, therefore,
> doesn't make sense and can only lead to obscure bugs.
>
Instead of disallowing code, this is a case for allowing with expressions:
def read_multiple(*filenames):
for filename in filenames:
yield (f.read() with open(filename) as f)
Elazar
___
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] PEP 505: None-aware operators
Just wanted to note another possibility (most likely to be added to the "rejected solutions" section). Add a prefix "!" operator, which will work similarly to the iterator-unpacking operator "*", but for None. The expression "[!x]" is equivalent to the expression "[] if x is None else [x]". This can be combined with the "or" operator, now working as expected since it's about lists, and a simple "first" or "single" library function. Example: optdict = dict(encoding=single([!encoding] or sys.getdefaultencoding()), css=options.css) It is more verbose than the proposed "??" operator (which I personally like), but maybe it's less line noise. One can use it with simple parens and get a tuple, "(!x) or y". note that "(!x or y)" is a syntax error in this case. Another, related idea: instead of "??" use a double-token operator "! or": value = ham! or spam! or eggs optdict = dict(encoding=encoding! or sys.getdefaultencoding(), css=options.css) Elazar ___ 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] PEP 505: None-aware operators
On Wed, Jul 25, 2018 at 3:11 PM Abe Dillon wrote: > The problem here is not whether it's explicit. It's about Readability and > conciseness. Using symbols in place of words almost always harms > readability in favor of conciseness. > > value = person.name if person.name else person > > almost reads like english (aside from being a weird and totally uncommon > use case) > > value = person?.name > > Is a huge step towards the concise illegible soup of symbols that Perl is > famous for. It's a huge No from me. > > > Similarly, Value is name of person almost reads like english. value = person.name Starts to look like pearl (but does not avoid repetition; only hurts english-like-readability) - or perhaps some other programming languages that use similar operators, such as C#, Swift, Dart, F#, Kotlin and others. As far as I know it is not generally considered a bad addition in any of these languages, all of which put emphasis on readability. Elazar ___ 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] PEP 505: None-aware operators
On Thu, Jul 19, 2018 at 11:37 AM Brendan Barnwell wrote: > > As far as I can see, these null-coalescing operators would break > that > model. The PEP doesn't seem to provide for a "real" magic method > allowing users to override the actual behavior of the method. (You can > only override __has_value__ to hook into it, but not define by fiat what > A ?? B does, as you can with other operators.) And I think the reason > for this is that the operator itself is too specific, much more specific > in semantics than other operators. (I had similar doubts about adding > the matrix-multiplication operator @.) > It is just as specific as the `is` operator, and for the same reason. Elazar ___ 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] Should nested classes in an Enum be Enum members?
Yes, Ryan. I mean a way to express something like sealed classes in scala/kotlin. The Enum class defines a finite region in which subclasses can be defined, thus allows verifying that "elif" cases are exhaustive, for exampe. It mostly helpful for static type checking, but it also helps readability and is a natural way to describe ASTs. class Expr(Enum): class BinOp(NamedTuple): # ideally should subclass Expr left: Expr right: Expr op: str class UnOp(NamedTuple): operator: Expr operand: str ... It's one of the (rejected) ideas here: https://github.com/python/mypy/issues/2464 Not the best link out there but it explains: https://antonioleiva.com/sealed-classes-kotlin/ Elazar On Wed, Jun 27, 2018 at 12:49 PM Ryan Gonzalez wrote: > I *think* he's referring to something like this: > > class A(enum.Enum): > class Inner(NamedTuple): > ... > > isinstance(A.Inner(), A()) # True > > I *think* that's it. > > > > On June 27, 2018 2:26:23 PM Ethan Furman wrote: > > > On 06/27/2018 12:04 PM, Elazar wrote: > > > בתאריך יום ד׳, 27 ביוני 2018, 11:59, מאת Guido van Rossum: > > > > >> Sounds to me really strange that the nested class would become a > member. > > >> Probably because everything becomes a member unless it's a function > > >> (maybe decorated)? > > > > >> People working with sum types might expect the instances of the nested > > > class to be instances of the enclosing class. So if the nested class > is > > > a namedtuple, you get a sum type. The only problem is that there's no > > > way to express this subtype relationship in code. > > > > I have no idea what you just said. :( Is there a link you can share > that > > might explain it? > > > > -- > > ~Ethan~ > > ___ > > 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/ > ___ 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] Should nested classes in an Enum be Enum members?
People working with sum types might expect the instances of the nested class to be instances of the enclosing class. So if the nested class is a namedtuple, you get a sum type. The only problem is that there's no way to express this subtype relationship in code. Elazar בתאריך יום ד׳, 27 ביוני 2018, 11:59, מאת Guido van Rossum : > Sounds to me really strange that the nested class would become a member. > Probably because everything becomes a member unless it's a function (maybe > decorated)? > > On Wed, Jun 27, 2018 at 7:47 AM Ethan Furman wrote: > >> Consider the following Enum definition: >> >>class Color(Enum): >>RED = 1 >>GREEN = 2 >>BLUE = 3 >>@property >>def lower(self): >>return self.name.lower() >>def spam(self): >>return "I like %s eggs and spam!" % self.lower >>class SomeClass: >>pass >> >> Which of the above Color attributes are enums, and which aren't? >> >> >> . >> >> >> . >> >> >> . >> >> Answer: >> >>- RED, GREEN, and BLUE are members >> >>- lower and spam() are not >> >>- SomeClass /is/ a member (but not its instances) >> >> >> Question: >> >>Should `SomeClass` be an enum member? When would it be useful to have >> an embedded class in an Enum be an enum member? >> >> >> The only example I have seen so far of nested classes in an Enum is when >> folks want to make an Enum of Enums, and the >> nested Enum should not itself be an enum member. Since the >> counter-example already works I haven't seen any requests >> for it. ;) >> >> So I'm asking the community: What real-world examples can you offer for >> either behavior? Cases where nested classes >> should be enum members, and cases where nested classes should not be >> members. >> >> Thanks! >> >> -- >> ~Ethan~ >> ___ >> Python-ideas mailing list >> Python-ideas@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > -- > --Guido van Rossum (python.org/~guido) > ___ > 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] ternary without else
The title is misleading - this has nothing to do with the conditional operator, except small syntactic similarity. Elazar בתאריך יום ו׳, 25 במאי 2018, 05:40, מאת Jacco van Dorp < j.van.d...@deonet.nl>: > 2018-05-25 14:26 GMT+02:00 Kirill Balunov <kirillbalu...@gmail.com>: > > If it is an expression, what should `do_something if cond` return on > > failure? If you don't care you can already use `cond and do_something`. > > Duh, forgot to mention. > I wouldn't have it return anything. Ternary returns something because > you have two options and picks one. This is conditional execution of a > statement. I guess it would be a statement, like normal if. > > I guess cond and do_something would be equivalent, but that's not > really the intention of and/or, no matter how much it's used for this > sort of thing. > > Disclaimer: > I don't really expect this to be accepted. It's more of a minor gripe > i've occasionally had. This afternoon, I wrote: > > if not article["art_wt"]: article["art_wt"] = 0 > if not article["px_pchs"]: article["px_pchs"] = 0 > if not article["px_calc"]: article["px_calc"] = 0 > if not article["px_sell"]: article["px_sell"] = 0 > > while preparing a dict for import in accountview. I try not to make a > habit of dismissing syntax warnings. I consider the code above > abundantly clear (no, I dont know what those keys mean. Since I have > no power over that, I dont consider it detrimental to clarity.) > ___ > 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] A way to subscript a single integer from bytes
I think this method is easy to miss, since people look at the docs for bytes (e.g. using dir(bytes)). It might be worthwhile to either add a `bytes.to_int(...)` method (better, IMHO), or to point to int.from_bytes on the relevant part of the docs. Elazar On Tue, May 1, 2018 at 5:09 PM Ken Hilton <kenlhil...@gmail.com> wrote: > Whoops! Never seen that before. Nothing I searched up pointed me to it. > Sorry for wasting your time! > > Ken; > -- > Sincerely, > Ken; > ___ > 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] Rewriting file - pythonic way
This pitfall sounds like a good reason to have such a function in the standard library. Elazar בתאריך יום א׳, 15 באפר׳ 2018, 13:13, מאת Serhiy Storchaka < storch...@gmail.com>: > 15.04.18 12:49, Alexey Shrub пише: > > В Воскресенье, 15 апр. 2018 в 12:40 , Serhiy Storchaka > > <storch...@gmail.com> написал: > >> If the problem is that you want to use a single line instead of three > >> line, you can add a function > > > > Yes, I think that single line with word 'rewrite' is much more readable > > than those three lines. > > And yes, I can make my own function, but it is typical task - maybe it > > must be in standard library? > > Not every three lines of code must be a function in standard library. > And these three lines don't look enough common. > > Actually the reliable code should write into a separate file and replace > the original file by the new file only if writing is successful. Or > backup the old file and restore it if writing is failed. Or do both. And > handle hard and soft links if necessary. And use file locks if needed to > prevent race condition when read/write by different processes. Depending > on the specific of the application you may need different code. Your > three lines are enough for a one-time script if the risk of a powerful > blackout or disk space exhaustion is insignificant or if the data is not > critical. > > ___ > 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] Fixing class scope brainstorm
On Sun, Mar 25, 2018 at 5:51 PM Guido van Rossum <gu...@python.org> wrote: > In the PEP 572 threads there's some grumbling about class scopes. > > Here's a random brainstorm. How about we change the scoping rules so that > only functions defined with 'def' (or inside one of those) cannot see the > class scope, and comprehensions and lambdas treat the class scope as an > outer scope so they can close over class variables? > > Not sure what should happen to nested classes, they should probably be > lumped in with the 'def' scopes. > > I would expect classes to behave like comprehensions - i.e. code that is not delayed will see the class' scope as an enclosing scope (since it is not namespaced yet so there's no other way to refer to it) and delayed code (e.g. lambdas or defs) will not. Elazar ___ 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] Descouraging the implicit string concatenation
On Wed, Mar 14, 2018 at 8:43 PM Robert Vanden Eynde <
robertvandeney...@hotmail.com> wrote:
> > We should write the following, instead:
> >
> > long_string = (
> > "some part of the string " +
> > "with more words, actually is the same " +
> > "string that the compiler puts together")
>
> Maybe the "+" at the beginnig as PEP8 said, to clearly mark it present
> and explicit.
>
> long_string = (
> "some part of the string "
> + "with more words, actually is the same "
> + "string that the compiler puts together")
>
> or
>
> long_string = (""
> + "some part of the string "
> + "with more words, actually is the same "
> + "string that the compiler puts together")
>
>
>
Or allow unary plus:
long_string = (
+ "some part of the string "
+ "with more words, actually is the same "
+ "string that the compiler puts together"
)
Elazar
___
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] [Python-Dev] What's the status of PEP 505: None-aware operators?
On Wed, Nov 29, 2017 at 3:12 PM Serhiy Storchaka <storch...@gmail.com> wrote: > 29.11.17 15:01, Stephan Houben пише: > > What about a more general: > > > > A if B else C > > > > which would allow > > > > A if is not None else C > > > > but also e.g. > > > > A if >= 1 else 0 > > This look the most "natural" to me. I.e. the least "unnatural". If we > even will introduce a new special syntax I will prefer this syntax. > > The only disadvantage is that this will prevent introducing "angular > parenthesis" in future: A if <X, Y, Z> == B else C. > > Also, how do you treat more complex conditions? do you prohibit them? A if >= 0 and < 2 else 0 B if >= 0 or < -1 else -1 C if and B else A # i.e. C if C and B else E D if -y else E # is this an unary minus or a binary operation? If any of these is allowed, it might confuse people. It also break the ability to extract subexpression to variables. (I kinda like this idea, but it doesn't look like a small, simple change to the language, whereas ?? does). Elazar ___ 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] [Python-Dev] What's the status of PEP 505: None-aware operators?
בתאריך יום ד׳, 29 בנוב׳ 2017, 12:29, מאת Lele Gaifax <l...@metapensiero.it >: > Kirill Balunov <kirillbalu...@gmail.com> writes: > > > Since the proposed semantics is more similar to the idea of "or", may be > it > > is better to consider something like: > > > > timeout then local_timeout then global_timeout > > > > I do not know how much this is a frequent case to be worthy of a keyword. > > That sounds awkward... what about > > timeout else local_timeout else global_timeout > > instead? > I think then and else can be ruled out since they can be very confusing when used in a conditinal statement or a comprehension. x = a if x else y else b # wait. what? Elazar ___ 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] [Python-Dev] What's the status of PEP 505: None-aware operators?
בתאריך יום ד׳, 29 בנוב׳ 2017, 11:46, מאת Steven D'Aprano < st...@pearwood.info>: > On Wed, Nov 29, 2017 at 09:14:12AM +0200, Serhiy Storchaka wrote: > > 29.11.17 08:08, Steven D'Aprano пише: > > >Perl is hardly the only language with null-coalescing operators -- we > > >might better describe ?? as being familiar to C#, PHP, Swift and Dart. > > >That's two mature, well-known languages and two up-and-coming languages. > > > > What is the syntax of the ternary operator in these languages? > > All four use: > > condition ? first : second > > for the ternary if operator. > This suggests something like "ifNone" keyword : x = a ifNone b ifNone c Elazar ___ 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] Repurpose `assert' into a general-purpose check
On Tue, Nov 28, 2017 at 6:08 PM Ivan Pozdeev via Python-ideas <
python-ideas@python.org> wrote:
> On 28.11.2017 16:36, Nick Coghlan wrote:
>
> > On 28 November 2017 at 15:41, Steven D'Aprano <st...@pearwood.info>
> wrote:
> >> On Tue, Nov 28, 2017 at 05:12:36AM +0300, Ivan Pozdeev via Python-ideas
> wrote:
> >>> Unlike C, Python does the aforementioned checks all the time, i.e. it's
> >>> effectively always in "debug mode".
> >> Apart from -O which disables assertions. But in any case, the best use
> >> of assertions is not checking things which the interpreter is going to
> >> do anyway, but checking things which the interpreter can not and does
> >> not check automatically: your program logic. There is no way that the
> >> Python interpreter is going to do this check automatically, unless I
> >> write the assertion:
> >>
> >> assert 0 <= r < abs(y)
> >>
> >> That is copied straight out of one of my functions.
> > I'll make the same observation I usually do each time one of these
> > threads comes up:
> >
> > * I'm opposed to making assert substantially different from the way it
> works now
> > * I'm in favour of adding a new "ensure()" builtin that encapsulates
> > the check-and-raise logic
> >
> > The reasons I prefer this approach:
> >
> > - assert is a statement *solely* so that the compiler can optimise it
> > out. If it's not optional,
> >it doesn't need to be a statement any more
> Another benefit of a statement vs function is only evaluating the
> error-related arguments when there's an error
>
I'm not sure what the use case is, but it could be implemented easily as
ensure(not hasattr(e, "exception")) or raise e.exception
... had "raise" been an expression, an idea repeatedly rejected here. It's
still implementable with a "throw()" function.
Elazar
> > - if the existing assert statements are left alone, there are no
> > performance or compatibility
> >concerns for folks that rely on the current behaviour
> > - if it's a function, it doesn't need to be called "assert", it can use
> the more
> >imperative term "ensure" (meaning "ensure this condition is true
> > before continuing")
> > - if it's a function, it can easily be emulated on old versions via
> > compatibility libraries
> > - "ensure() is required, assert is optional" is a better answer to
> > complaints about
> >assertions being optional than suggesting "if cond: raise
> AssertionError(msg)"
> >as a reasonable alternative to "assert cond, msg"
> > - if it's a function, we get access to all the regular function
> > machinery, so we're
> >not restricted to positional-only arguments the way the assert
> statement is
> >
> > My initial proposed behaviour for the function:
> >
> > def ensure(cond, msg=None, exc_type=RuntimeError):
> > """Raise an exception if the given condition is not true"""
> > if not cond:
> > if msg is None:
> > frame = sys._getframe(1)
> > line = frame.f_lineno
> > modname = frame.f_globals.get("__name__", " module>")
> > msg = f"Condition not met on line {line:d} in
> {modname!r}"
> > raise exc_type(msg)
> >
> > Cheers,
> > Nick.
> >
> > P.S. No, I'm not offering to write that PEP myself, I'd just be in
> > favour of the idea if someone else were to write it :)
> >
>
> --
> Regards,
> Ivan
>
> ___
> 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] Repurpose `assert' into a general-purpose check
Just a note : in typechecked code (such as mypy's source code) assert is used to guide the checker: assert isinstance(x, CallableType) return x.args # checker knows it's valid So the assert becomes a kind of type annotation. The runtime check helps during tests, but is not that important - failure will be caught relatively soon. And I believe that the ability to remove the check at runtime is important, since isinstance calls have non-negligible impact on performance in mypy. (but other contributors here can correct me on this). Elazar בתאריך יום ג׳, 28 בנוב׳ 2017, 09:12, מאת Ivan Pozdeev via Python-ideas < python-ideas@python.org>: > On 28.11.2017 8:59, Steven D'Aprano wrote: > > On Tue, Nov 28, 2017 at 07:35:45AM +0300, Ivan Pozdeev via Python-ideas > wrote: > > > >> Actually, the way I'm using them, > >> > >> assert condition, "error message", type > >> > >> would probably be the most expressive way. > > I disagree that is expressive -- I call it *misleading*. I see something > > which looks like an assertion (that is, a checked comment, a contract, a > > check on an internal piece of logic etc) but it is actually being used > > as a test. > > > > > >> I can do anything in any Turing-complete language without any changes to > >> the language. That's no reason to never change anything, is it. > > "We can change this" is not a reason to change this. There needs to be a > > *good* reason to change, and you have given no good reasons for this > > change. > > > > > >> The rationale basically is: > >> * As it was intended, the statement has no practical use -- basically a > >> rudiment, due to disappear eventually > > Nonsense. I make extensive use of assert as a way of checking > > assertions, and I will fight tooth and nail against any proposal to > > either remove it or to misuse it for public input tests instead of > > assertions. > I invite you to show me a single use case for those "assertions" because > after ~20 years of experience in coding (that included fairly large > projects), I've yet to see one. > > Any, every check that you make at debug time either > * belongs in production as well (all the more because it's harder to > diagnose there), or > * belongs in a test -- something coded independently from the program > (if your code as a whole cannot be trusted, how any specific part of it > can?), or > * isn't needed at all because a fault will inevitably surface somewhere > down the line (as some exception or an incorrect result that a test will > catch). > > Finally, I've got much experience using existing code outside its > original use cases, where the original author's assumptions may no > longer hold but the specific logic can be gauded to produce the desired > result. Coding these assumptions in would undermine that goal. > > So, I see "debug assertions" as either intentionally compromizing > correctness for performance (a direct opposite of Python's design > principles), or as an inferiour, faulty, half-measure rudiment from > times when CI wasn't a thing (thus not something that should be taught > and promoted as a best practice any longer). > > > >> * It can instead be reused as syntax sugar to cover a very common use > case > > There is no need for such syntactic sugar. It would be harmful > > to use assert for something which is not an assertion. > > > > > > > > -- > Regards, > Ivan > > ___ > 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/
