[Python-ideas] Re: Add an __exclude_all__ complement to __all__

Why not just __exclude__ or __excluding__? On Wed, Mar 3, 2021 at 2:57 PM George Harding < george.winton.hard...@gmail.com> wrote: > Hi, > > Python has an __all__ variable that can be defined in a module to restrict > which members of the module should be included in a call `from foo import > *`.

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

I like the => syntax and would use it probably 80% of the time for mutable defaults. I don't think it causes cognitive load. I especially disagree with the argument that it looks like arbitrary symbols and adds more 'line noise' than a keyword. My eye picks it up as a distinct arrow rather than a

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

"You've gone from talking about *my* intentions, which you got wrong, to an argument about which is "more explicit"." No. You were the one who brought up explicitness by claiming that using a sentinel value was a way to "explicitly tell the function "give me the default value" (whatever the heck t

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

s and that unbound variables cause errors and now you're pulling __name__ out of thin air? Where the heck did that come from? Anyway, this is a tangent I promised myself I wouldn't go on... On Thu, Dec 2, 2021 at 11:16 PM Chris Angelico wrote: > On Fri, Dec 3, 2021 at 3:47 PM Abe D

Re: [Python-ideas] PEP 505: None-aware operators

> > Do you know what helps readability? *Learning to read* Do you know what helps? *leveraging intuition* If you're going to throw a question mark in there, which by the way, is far more visually intrusive than a '.', then it makes more sense to at least try to use it in a familiar way: v = (a.b)

Re: [Python-ideas] PEP 505: None-aware operators

The readability issue isn't just a matter of a new set of symbols to learn. It isn't even that the symbols are used in a non-intuitive way (though that doesn't help). It's not even that the question mark, unlike the dot, is very visually obtrusive (which also doesn't help). It also screws with the

Re: [Python-ideas] PEP 505: None-aware operators

e end of a clause... your use of "?" does not conflict with any use in the PEP, so this is a red > herring. I suppose it doesn't *technically* conflict, but it would lead to some beautiful code, like: lambda data=a?.b?[0]?: data?.d On Fri, Jul 27, 2018 at 7:00 AM, Rhodri Jame

Re: [Python-ideas] PEP 505: None-aware operators

d to explain how two-character operators work? Point taken, I'll watch my tone. Rhodri James, I'm sorry for that flippant remark about order of operations. It was uncalled for. On Sat, Jul 28, 2018 at 3:14 PM, Chris Angelico wrote: > On Sun, Jul 29, 2018 at 6:07 AM, Abe Dillon wrot

Re: [Python-ideas] PEP 505: None-aware operators

First of all: Thanks to everyone for explaining everything about the id function. You are all so smart... [Greg Ewing] > Dots have been used for attribute access in so many languages > for so long that it has become the normal and expected syntax > to use. ?. is much more recent. Maybe in another

Re: [Python-ideas] PEP 505: None-aware operators

[Chris Angelico] > Almost. Except for the problem that "disgusting" is a subjective term. Yes. Thank you for explaining the joke. [Brice Parent] > I don't believe we need spam.eggs.cheese.aardvark? (there is exactly the > same number of use cases). We win a bit in readability as it's closer t

Re: [Python-ideas] Proposed alternative postfix syntax [was PEP 505: None-aware operators]

[Steve D'Aprano] > so you absolutely are claiming that dot access "isn't *that* different" > from the possessive in English. Only in the context that I gave: `person.name`. In other contexts (e.g. thing.is_metal) the possessive analogy is obviously inaccurate, but I didn't make the broad claim t

Re: [Python-ideas] Proposed alternative postfix syntax [was PEP 505: None-aware operators]

initials = [person.name[0] for person in people return Counter(initals).most_common(1)[0] You, as a human, can probably guess with extremely high certainty that I meant to put a ']' at the end of the second line. In that sense, it's redundant to you, but not to the computer which does

Re: [Python-ideas] Proposed alternative postfix syntax [was PEP 505: None-aware operators]

Typo: *You can usually guess that, since `person` isn't a local variable, we're probably dealing with a generator *comprehension* On Sun, Jul 29, 2018 at 11:00 PM, Abe Dillon wrote: > [Steven D'Aprano] > >> really wish you would stop talking about "natural langua

Re: [Python-ideas] PEP 505: None-aware operators

In that case; person.name would evaluate to some result or throw an un-guarded AttributeError, in the former case the to the left of the '?' is an attribute access on the result of (person.name). In the latter case; an AttributeError is thrown. That seems pretty straight forward. No?

Re: [Python-ideas] With expressions

I like this idea in theory, but I'm not sold yet. I think there's a lot of draw to the concept of "expressionizing" statements because many statements require an unnatural ordering in-which the most important code, the logic, comes after some necessary but ultimately noisy (from the readers perspe

Re: [Python-ideas] With expressions

[Benedikt Werner] > As the with-expression mimics the with-statement I would say this is > similar to: > with supress(AttributeError): > tmp = person.name[0] > initial = tmp # Error on assignment wouldn't get suppressed. Not relevant > for this case but still. Ah, yes. That makes much more s

Re: [Python-ideas] With expressions

it does and it only adds 7 characters). On Fri, Aug 3, 2018 at 6:57 PM, Abe Dillon wrote: > [Benedikt Werner] > >> As the with-expression mimics the with-statement I would say this is >> similar to: >> with supress(AttributeError): >> tmp = person.name[0] >&g

Re: [Python-ideas] Syntactic sugar to declare partial functions

I'd like to push for the less jargon-y `func.given()` version if this gains traction. Not only is it shorter, it's a much more common term with a clear meaning. Words like 'partial', 'curry', 'lambda', and 'closure' are fine for text books, published papers, and technical discussion, but I think th

Re: [Python-ideas] Syntactic sugar to declare partial functions

ould use Egyptian Hieroglyphs then. Even the playing field. It doesn't matter anyway, right? It's all nonsense to someone... Honestly, I don't think 'partial' is that bad. I just wanted to support your own comment: although possibly a less jargon name would be nicer: >

Re: [Python-ideas] Syntactic sugar to declare partial functions

anti-jargon example. Anonymous functions are not a confusing concept, yet people get caught up on it surprisingly frequently. I think the name is partly to blame. On Fri, Aug 10, 2018 at 5:42 PM, Neil Girdhar wrote: > > > On Fri, Aug 10, 2018 at 6:21 PM Abe Dillon wrote: > >>

Re: [Python-ideas] Syntactic sugar to declare partial functions

"partial", we ought to > be > clear about the reasons why. I gave my reasons: it's shorter and less jargon while remaining fairly clear (in my opinion) You've already claimed that "possibly a less jargon name would be nicer", so I don't see the fuss. Apparent

Re: [Python-ideas] Syntactic sugar to declare partial functions

he correct choice here. I disagree. This forum is looking more and more toxic. I've explained myself over and over again. I just wanted to +1 Steven's original comment. This is ridiculous. I guess I've pissed of the good-old-boys by calling out Steven's unnecessary condescensio

Re: [Python-ideas] Syntactic sugar to declare partial functions

I have no reason to respond. Your example looks nothing like what I've suggested and this whole conversation is being derailed by your need to win the argument. On Mon, Aug 13, 2018 at 12:04 AM, Chris Angelico wrote: > On Mon, Aug 13, 2018 at 2:56 PM, Abe Dillon wrote: > > [Chris

Re: [Python-ideas] Toxic forum

This is a half-baked thought, but perhaps a sub-reddit would facilitate better moderation and we'd get the bonus of threaded discussions and a side-bar for ediquite and other important info. I know Reddit has a mixed reputation, but some of the best moderated subs like /r/science and /r/neutralpol

Re: [Python-ideas] Syntactic sugar to declare partial functions

[Bruce Leban] > Lambda calculus IS computer science. It's a foundation of computer science. That doesn't mean it "IS" computer science. Set theory is a foundation of computer science. It's still it's own discipline. [Bruce Leban] > Rejecting lambda as CS is as bad as rejecting the + operator b

Re: [Python-ideas] Syntactic sugar to declare partial functions

#x27;t seem to matter how many times I try to point this out, but my original comment should be read as: "I like Steven's idea. I prefer `given` to `partial`." I'm sorry I even brought up lambda. I'm truly sorry to all those who wanted to seriously discuss alternatives t

Re: [Python-ideas] Conduct on python-ideas

I can respect that. I'll take a week off the list and try to check myself in the future. I'm sorry to everyone on python-ideas. I'm sorry Steven. On Mon, Aug 13, 2018 at 2:38 PM, Brett Cannon wrote: > I'm starting a new thread on this to make sure it receives appropriate > visibility for everyon

Re: [Python-ideas] Syntactic sugar to declare partial functions

[Steven D'Aprano] > - I accept that there've been a few cases where I could have > chosen my words better, and consequently I've rubbed Abe > the wrong way; sorry about that Abe, as I said earlier (and > I meant it) I have no grudge against you. Thank you. I hold no grudge against you eith

Re: [Python-ideas] Jump to function as an an alternative to call function

Jumping into functions that mutate variables in the calling scope sounds a lot like "GoTo" which is notorious for leading to code that's very hard to reason about. Your functions would implicitly require that you assign variables in the calling sco

Re: [Python-ideas] Jump to function as an an alternative to call function

ems trying to use the Google Groups interface to post, so I've resorted to strictly using email. Unfortunately, that makes the structure of the conversation less obvious to me. I'll try to be more mindful of this in the future. On Wed, Aug 15, 2018 at 4:58 PM, Chris Angelico wrote: >

Re: [Python-ideas] Jump to function as an an alternative to call function

Sorry for the double post, but I wanted to make sure you saw my original misplaced post: Jumping into functions that mutate variables in the calling scope sounds a lot like "GoTo" which is notorious for leading to code that's very hard to reason a

Re: [Python-ideas] Jump to function as an an alternative to call function

[Jacob Solinsky] > these local variables are used quite often in the mutate methods, of which > there are several dozen, so storing them by default saves a lot of typing. There are several things you can do to alleviate the typing problem: 1) Get an IDE that has auto-complete. I recommend PyChar

Re: [Python-ideas] Jump to function as an an alternative to call function

Jacob, can you please describe in greater detail *what* you're trying to accomplish with your morpheme code? Not *how* you wish to accomplish it, but *what* the code is supposed to do? I've looked into other projects that try to model morphemes and similar language constructs to get a better idea

Re: [Python-ideas] Jump to function as an an alternative to call function

d pasted many times. > > The code I wrote already functions fine, it is just that while I was > writing I was thinking to myself how convenient it would be if I could > "jump to" functions, and now I understand that the best way to do that > would just be to macro expand

Re: [Python-ideas] Does jargon make learning more difficult?

[Michael Selik] > The conversation about syntactic sugar for ``functools.partial`` led to a > question about whether jargon like "lambda" makes the concept of an > anonymous function more difficult to learn. To clarify: The original statement by Steven D'Aprano, "although possibly a less jargon

Re: [Python-ideas] Does jargon make learning more difficult?

Responding out of order. [Rhodri James] > > For instance: when the iPhone was introduced, a lot of people praised > > it's subjectively "slick" user interface. I believe that perception of > > slickness is partly because the iPhone emulated physical interfaces > > very well so it leveraged people

Re: [Python-ideas] Does jargon make learning more difficult?

[Stephen Turnbull] > I was an economist then, and I'm an economist still, but I met lambda > in 1977. Surely lambda has had that role in computer languages since > shortly before I was born. According to Wikipedia Lisp was the first language to

Re: [Python-ideas] Does jargon make learning more difficult?

= sorted(cards, by=value[card.suit] if card not in wilds else max_value with card) [Chris Angelico] > In English, "card is not wild" can > be interpreted as a membership check, but in Python, it is only an > identity check; you're capitalizing on false readability by using th

Re: [Python-ideas] Does jargon make learning more difficult?

will NOT be your main source of confusion. If you do know what "".join() does, then it should take you much less context to realize you're reading a generator expression. By the time you read the yet-to-be-assigned "name" variable you should be tipped off. On Tue

Re: [Python-ideas] Does jargon make learning more difficult?

've found that if you're trying to model a game like poker or Monopoly, it's tempting to add complexity to simple objects, but it can lead to problems later on. A card doesn't know if it's wild. That's a function of the game being played. An ace may be high or low. On

Re: [Python-ideas] Does jargon make learning more difficult?

[Jonathan Fine] > I have reservations about the name lambda. But there's a lot of > code out there that uses lambda, and I'd like that code to continue to > run. Yes. I'm under no delusion that lambda will be replaced any time soon. Nor do I believe any alternative I suggest will be enough of an

Re: [Python-ideas] Does jargon make learning more difficult?

[Chris Angelico] > Python's parser is *deliberately* incapable of backtracking this far > in its definition of syntax. Can you explain how far the parser is capable of backtracking? It seems like with would require a similar amount of backtracking to ternary expressions: if else If the pr

Re: [Python-ideas] Does jargon make learning more difficult?

[Chris Angelico] > I have to defer to someone who knows in more detail here, but the > parser will look ahead one "token", whatever a token is. (Technically > it doesn't backtrack, it looks ahead - same difference.) In order for > the ternary-if to work, the expression before the if has to be of a

Re: [Python-ideas] A simple proposal concerning lambda

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

Re: [Python-ideas] A simple proposal concerning lambda

[Jonathan Fine] > 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 Awesome! Unfo

Re: [Python-ideas] A simple proposal concerning lambda

[Steven D'Aprano] > most importantly, "def" with "fun", which will have the > advantage of making Python programming more fun! I'm sold. Make the change and SHIP IT! No need for committee approval. [Steven D'Aprano] > If we're going to break people's code by > changing keywords, let's do it pr

Re: [Python-ideas] A simple proposal concerning lambda

[Chris Angelico] > If you have a use-case for a lambda function that takes a callback and > has a default value for that callback, please submit it to The Daily > WTF. In Steve's example, the main function was created with a > statement. Fair enough, but I still think D'Aprano may have engineere

Re: [Python-ideas] A simple proposal concerning lambda

because, like ternary and other circuiting operations, the expression isn't evaluated until certain criteria are met. The arrangement shouldn't matter. ...I think. On Tue, Aug 21, 2018 at 10:10 PM Chris Angelico wrote: > On Wed, Aug 22, 2018 at 12:57 PM, Abe Dillon wrote: > &g

Re: [Python-ideas] Does jargon make learning more difficult?

[Steven D'Aprano] > > The revelation that it's a function should come when you read the "by" or > > "key". > I disagree. The most important fact is that it is a function, not > specifically what it does. I was trying to say that the context almost always gives away that the reader should expect

Re: [Python-ideas] Does jargon make learning more difficult?

Replying out of order: [Steven D'Aprano] > Under your proposal, that becomes: > def bench(name, cleanup=None with ???, *, seconds=1, repeat=3): > except I'm not really sure what goes in the ??? for an empty parameter > list. I know I tend to write long-winded responses, but please read them ful

Re: [Python-ideas] Does jargon make learning more difficult?

Thanks, Stephen. That's interesting. So the parser can see one token past, for instance; what would be the end of an expression, see "if", and know to expand the AST? ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/l

Re: [Python-ideas] Does jargon make learning more difficult?

[Steven D'Aprano] > As educators, if we fail to teach the technical language of a field to > our students, we are failing to prepare those students to enter that > field. Technical jargon is the language of the field. It's not the responsibility of the tool to teach. My socket wrench doesn't hav

Re: [Python-ideas] Does jargon make learning more difficult?

[Chris Angelico] > If the concept is utterly unfamiliar and the word is familiar, it > creates a different problem: the false parallel. Let's suppose that, > instead of calling them "lambda expressions", we call them "bacon > expressions". Or maybe "curry expressions!"... (I really hate that jar

Re: [Python-ideas] Does jargon make learning more difficult?

[Chris Angelico] > Because your form cannot possibly work without some additional > information. That isn't my form. That's PSEUDO CODE. Just like I wrote above it. You're the one who's not listening. The alternative I've suggested, for the thousanth time, is: hand = sorted(cards, by=card.sui

Re: [Python-ideas] Does jargon make learning more difficult?

I'm at a loss for words. On Thu, Aug 23, 2018 at 12:21 AM Steven D'Aprano wrote: > On Thu, Aug 23, 2018 at 03:12:30PM +1200, Greg Ewing wrote: > > Abe Dillon wrote: > > >They still find it's better to use a red break > > >light symbol with the aim of cl

Re: [Python-ideas] Does jargon make learning more difficult?

ork was > published, the typesetter either misread it as a lambda > or subsituted a lambda because it was the closest thing > he had in his font, and from there on it stuck. > > > Abe Dillon wrote: > >>I've also argued that the very form of lambda expressions

Re: [Python-ideas] Does jargon make learning more difficult?

[Steven D'Aprano] > If you go back far enough, pretty much all words and written symbols are > arbitrary. I think this is wandering into nihilistic pedantry. Go back or forward far enough (or zoom in or out far enough) and nothing means anything. When I first learned Python, I had never heard t

Re: [Python-ideas] Does jargon make learning more difficult?

Let me preface this by saying: I've already addressed the possibility of a form that tells you up-front that it's a function Granted it was 8 replies ago and at the end of a long-winded response, so I'll summarize here: A format like [] would, in my view, be preferable to a format that puts the si

Re: [Python-ideas] Python dialect that compiles into python

[Steven D'Aprano] > It would be great for non-C coders to be able to prototype proposed > syntax changes to get a feel for what works and what doesn't. I think it would be great in general for the community to be able to try out ideas and mull things over. If there was something like a Python F

Re: [Python-ideas] Positional-only parameters

That looks great to me! I also think the '/' syntax looks fine and the pun works. If part of the motivation for position-only arguments was better performance and that motivation still holds water, then it makes sense to allow Python to support that optimization, but I would be happy with just a de

Re: [Python-ideas] Positional-only parameters

[Cameron Simpson] > I've been writing quite a few functions lately where it is reasonable for > a > caller to want to pass arbitrary keyword arguments, but where I also want > some > additional parameters for control purposes. I've run into this before and use the trailing '_' convention for nam

Re: [Python-ideas] Add "default" kwarg to list.pop()

I don't understand the rationale behind PEP 463's rejection. Guido says, "I disagree with the position that EAFP is better than LBYL, or "generally recommended" by Python. (Where do you get that?..."; but it's been in the official Python.org docs for a whil

Re: [Python-ideas] Add "default" kwarg to list.pop()

simply rejected the syntax choice because I disliked the syntax choice... On Tue, Nov 6, 2018 at 5:21 PM Steven D'Aprano wrote: > On Tue, Nov 06, 2018 at 01:03:54PM -0600, Abe Dillon wrote: > > > I don't understand the rationale behind PEP 463's rejection. Guido says

Re: [Python-ideas] Make None a subclass of int [alternative to iNaN]

I'm -1 on this idea. None is and should remain domain-independent. Specific domains may require additional special values like "NaN", "+/-inf", etc. for floating point math, in which case it makes more sense to define a domain-specific special value than compromise the independence of None. Doing s

[Python-ideas] [Brainstorm] Testing with Documented ABCs

I've been pulling a lot of ideas from the recent discussion on design by contract (DBC), the elegance and drawbacks of doctests , and the amazing talk given by

Re: [Python-ideas] [Brainstorm] Testing with Documented ABCs

[Marko Ristin-Kaufmann] > > Have you looked at the recent discussions regarding design-by-contract on > this list I tried to read through them all before posting, but I may have missed some of the forks. There was a lot of good discussion! [Marko Ristin-Kaufmann] > You might want to have a look

Re: [Python-ideas] [Brainstorm] Testing with Documented ABCs

[Steven D'Aprano] > You should look at the state of the art in Design By Contract. In > Eiffel, DBC is integrated in the language: > https://www.eiffel.com/values/design-by-contract/introduction/ > > https://www.eiffel.org/doc/eiffel/ET-_Design_by_Contract_%28tm%29%2C_Assertions_and_Exceptions > >

Re: [Python-ideas] [Brainstorm] Testing with Documented ABCs

s, it's a problem with the *system* not the instance. If you care about individual instances YOU'RE DOING IT WRONG. You need to re-design the system. On Wed, Nov 28, 2018 at 8:19 AM Antoine Pitrou wrote: > On Tue, 27 Nov 2018 22:47:06 -0600 > Abe Dillon wrote: > > > >

Re: [Python-ideas] [Brainstorm] Testing with Documented ABCs

gt; On Wed, 28 Nov 2018 15:58:24 -0600 > Abe Dillon wrote: > > Thirdly, Computers are very good at exhaustively searching > multidimensional > > spaces. > > How long do you think it will take your computer to exhaustively search > the space of possible input values to a

Re: [Python-ideas] __len__() for map()

I raised a related problem a while back when I found that random.sample can only take a sequence. The example I gave was randomly sampling points on a 2D grid to initialize a board for Conway's Game of Life: >>> def random_board(height: int, width: int, ratio: float = 0.5) -> Set[Tuple[int, int]]:

Re: [Python-ideas] [Brainstorm] Testing with Documented ABCs

Marko, I have a few thoughts that might improve icontract. First, multiple clauses per decorator: @pre( *lambda* x: x >= 0, *lambda* y: y >= 0, *lambda* width: width >= 0, *lambda* height: height >= 0, *lambda* x, width, img: x + width <= width_of(img), *lambda* y, height,

Re: [Python-ideas] [Brainstorm] Testing with Documented ABCs

approximately >> 6.6e8727169408. Let's hope the Sun takes its time. >> >> (and of course, what is true for ints is true for any variable-sized >> input, such as strings, lists, dicts, sets, etc.) >> >> Regards >> >> Antoine. &g

Re: [Python-ideas] [Brainstorm] Testing with Documented ABCs

know how you would handle more complex objects... do_stuff with_things Anyway. Just more food for thought... On Tue, Nov 27, 2018 at 10:47 PM Abe Dillon wrote: > I've been pulling a lot of ideas from the recent discussion on design by > contract (DBC),

Re: [Python-ideas] __len__() for map()

[David Mertz] > Do you anticipate that the `len()` function will be able to solve the > Halting Problem? > It is simply not possible to know whether a given iterator will produce > finitely many or infinitely many elements. Even those that will produce > finitely many do not, in general, have a

Re: [Python-ideas] __len__() for map()

That would be great especially if it returned objects of a subclass of map so that it didn't break any code that checks isinstance, however; I think this goes a little beyond map. I've run into cases using itertools where I wished the iterators could support len. I suppose you could turn those all

Re: [Python-ideas] [Brainstorm] Testing with Documented ABCs

ing with contracts using an existing library and just hold > their nose when writing the noisy syntax. Once we unearthed deeper problems > related to contracts, I think it will be much easier and much more > convincing to write a proposal for introducing contracts in the core > language.

[Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

I keep coming back to this great video about coding style, and one point in particular rings true to me: ALL_CAPS_IS_OBNOXIOUS It destroys the visual flow of code and for what? To signify a global, constant, or Enum? Is that really so important? I don't think so. I thi

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

t; from the case. > > Side note: it seems like ALL_CAPS kind of came from macros being using for > constants in C and persisted. > > -- > Ryan (ライアン) > Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else > https://refi64.com/ > > On Fri, Ja

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

ave a strong > standard today. > > -1 from me > > / Anders > > On 4 Jan 2019, at 20:01, Abe Dillon wrote: > > I keep coming back to this great video <https://vimeo.com/74316116> about > coding style, and one point in particular rings true to me: > ALL_CAPS_IS_O

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

hris Angelico wrote: > On Sat, Jan 5, 2019 at 10:10 AM Abe Dillon wrote: > >> > >> So you're saying we should prefer a future where it's an inconsistent > mess? > > > > No. And please don't straw man. It's a very annoying argumentative &g

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

> > Changing this in the PEP will make an absurd amount of code which is > PEP-8 compliant no longer so. It depends on how we change it. There's plenty of room to compromise between explicitly mandating all caps and explicitly forbidding all caps. We could simply remove the section that says to u

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

ss would say: > It's up to you whether you actually use final in > your own code or not, but IMO it is an extremely useful tool to > have in the toolbox, and should be kept. (and also you have to use it > because it's in the style guide) On Fri, Jan 4, 2019 at 5:41 PM

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

e you can write whatever value you want to pandas.cucumber because it isn't in all caps? On Fri, Jan 4, 2019 at 6:04 PM Michael Foord wrote: > > > On Fri, 4 Jan 2019 at 19:02, Abe Dillon wrote: > >> I keep coming back to this great video <https://vimeo.com/74316116

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

we just keep going through the motions even though it makes no sense. You just can't shake the notion that somehow, typing in all caps is a great way to convey information in code, when it's an extremely obnoxious means of conveying information in any other written form. On Fri, Jan 4,

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

;s not all caps, is it fair game to override it? Can you re-write your emote code so that it's clear that the emote-path variable is part of the API *without* any documentation? How much does all caps really communicate? On Fri, Jan 4, 2019 at 7:16 PM Chris Angelico wrote: > On Sat, Jan 5, 201

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

> Is it that really obnoxious? EXTREMELY! > Does using upper case for constants measurably slows down coders? Can you cite the actual papers describing such experiments that lead to this conclusion ? https://www.mity.com.au/blog/writing-readable-content-and-why-all-caps-is-so-hard-to-read https

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

cs onto the color axis works for us. So > we don't ban colorizing text and we shouldn't. > > Capitalizing constants may be slightly harder to read but constants in > code are the minority and emphasizing them is precisely the point. > > I'm MINUS_ONE on changing P

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

that claim on? I can tell that math.pi, string.digits, and timedelta.resolution are constants just fine. On Fri, Jan 4, 2019 at 9:42 PM Steven D'Aprano wrote: > On Fri, Jan 04, 2019 at 01:01:51PM -0600, Abe Dillon wrote: > > > I keep coming back to this great video <https:

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

Again, that's not always an option. On Wed, Jan 30, 2019 at 3:41 PM Chris Angelico wrote: > On Thu, Jan 31, 2019 at 8:23 AM Abe Dillon wrote: > > > > > Capitalizing constants may be slightly harder to read but constants in > code are the minority and emphasizing them i

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

tant. That's not the only argument he makes against all caps constants, though I agree that it's the strongest argument against all caps in Java. I largely agree with the rest of your post. I just don't think we need a naming convention for constants. On Fri, Jan 4, 2019 at 10:2

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

> > > Again, that's not always an option. > > > Again, that's not PEP 8's problem. It's my problem. It's a problem I have to deal with. It's a problem that doesn't need to be a problem. It's a problem that can be solved by modifying PEP-8. I

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

) come from. In my experience, most constants are configuration that people haven't decided to make configurable yet. I worked at a computer vision lab where the camera had a resolution of 640 x 480 which were originally represented as constants in a lot of our code VERTICAL_RESOLUTION

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

[Christopher Barker] > It’s a style *guide* folks — let it go! While I don't harbor any delusions that this is going anywhere (given the feedback so far), that's a double edged sword. It's also an extremely benign request, why fight so hard? On Wed, Jan 30, 2019 at 8:00 PM Christopher Barker w

Re: [Python-ideas] Potential PEP: with/except

[Calvin Spealman] > Why not allow excepts on fo loops, for example? Why not, indeed... I've heard there's a non-insignificant performance penalty for setting up a try statement, so it might be important to only set a for-loop up as a guarded for-loop upon reading the "except" statement (if the

Re: [Python-ideas] Clearer communication

I've pitched this before but gotten little feedback (especially positive feedback), but I think a Reddit-style forum would be a pretty vast improvement. We could easily start a python_ideas subreddit to try it out. I know the google group presents threaded conversations, but I've run into enough b

Re: [Python-ideas] Clearer communication

[Steven D'Aprano] > This isn't Facebook or Reddit, where +1 Likes cause messages to move to > the top of your feed. (And thank goodness for that.) This is a technical > mailing list where the worth of a proposals usually depends on merit, > not the number of votes. Since I just (almost simultane

Re: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

find that to be mildly interesting food for thought. Sorry for bumping this thread again... On Fri, Feb 1, 2019 at 12:59 PM Mike Miller wrote: > > On 1/30/19 6:07 PM, David Mertz wrote: > > On Wed, Jan 30, 2019, 4:23 PM Abe Dillon > <mailto:abedil...@gmail.com> wrote: > &g

Re: [Python-ideas] Clearer communication

e moderators. They cultivate a higher quality community by promoting a higher standard of interaction. On Fri, Feb 1, 2019 at 1:34 PM Dan Sommers < 2qdxy4rzwzuui...@potatochowder.com> wrote: > On 2/1/19 1:01 PM, Abe Dillon wrote: > > [Steven D'Aprano] > > > >> This

Re: [Python-ideas] Clearer communication

lopedia based on user-generated content could ever be useful. It's not even hard to make a subreddit. On Fri, Feb 1, 2019 at 3:06 PM Chris Angelico wrote: > On Sat, Feb 2, 2019 at 7:59 AM Abe Dillon wrote: > >> > >> Whoever posted last ends up at the bottom of the thre

Re: [Python-ideas] Clearer communication

little better than the timestamp on a post. It's not going to be perfect, but perfect shouldn't be the enemy of better. On Fri, Feb 1, 2019 at 3:17 PM Dan Sommers < 2qdxy4rzwzuui...@potatochowder.com> wrote: > On 2/1/19 2:58 PM, Abe Dillon wrote: > > [Dan Sommers] > >

  1   2   >