[Python-ideas] An option to force the path separator for the "os.path.join()" method.

I'd like to have an option to force the path separator for the "os.path.join()" method. E.g. if I run the script on Windows, but I generate, say, an URL, I'd find it convenient to use the same method, but with an explicit flag to "join" with the forward slash (because URLs use it). Currently I

[Python-ideas] Re: Escapes inside curly braces in f-strings

On Tue, Jun 30, 2020 at 5:05 AM Steven D'Aprano wrote: > For single-character escape codes, I see no benefit at all to this, only > disadvantages. However I do see a tiny potential benefit to hex escapes, > for the rare occassions that they are immediately followed by something > that looks like

[Python-ideas] Escapes inside curly braces in f-strings

Proposal: Allow standard python escapes inside curly braces in f-strings. Main point is to make clear visual distinction between text and escaped chars: # current syntax: print ("\nnewline") print ("\x0aa") # new syntax: print (f"{\n}newline") print (f"{\x0a}a")

[Python-ideas] Allow spaces between string prefix and the string literal

I would like to see possibility to put spaces between the string prefix and the string literal so I could write e.g. like this: print (f "x: {x}") IMO it would help with legibility especially noticable with by proportional fonts. Mikhail ___

[Python-ideas] syntax for dicts with arguments

Idea: how about an alternative syntax specifically for argument list definitions. To be able to write down a dict holding argument list in simpler form, namely with a function-like syntax: mystyle = dict ** (linestyle="dotted", marker="s", color= (0.1,0.1,0.0), markersize=4) as a synonym

Re: [Python-ideas] New explicit methods to trim strings

On Sun, Mar 31, 2019 at 3:28 AM Brandt Bucher wrote: > > > An idea worth considering: one can think of the “strip” family of methods > as currently taking an iterable of strings as an argument (since a string > is itself an sequence of strings): > > It would not be a huge logical leap to allow

Re: [Python-ideas] A directive for indentation type, stricter indentation parsing.

On Tue, Mar 26, 2019 at 2:02 PM Chris Angelico wrote: > > On Tue, Mar 26, 2019 at 9:49 PM Mikhail V wrote: > > Procedural removal is not cool, because it does not know the parent > > indentation > > [...] > > E.g. this: > > s = """

Re: [Python-ideas] A directive for indentation type, stricter indentation parsing.

On Tue, Mar 26, 2019 at 7:04 AM fhsxfhsx wrote: > > Just as to your example, you can try `textwrap.dedent` > Procedural removal is not cool, because it does not know the parent indentation of the statement that contains the text block, thus it can't resolve automatically string indents that were

[Python-ideas] A directive for indentation type, stricter indentation parsing.

Not a proposal yet, but some thoughts: I think it would help in a longer perspective if a user could include a directive in the header of the source code file that defines indentation character(s) for this source file. So this source would be parsed strictly by this char (or sequence). E.g.:

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

On Thu, Jan 31, 2019 at 4:59 AM Abe Dillon wrote: > [Steven D'Aprano] >> >> It seems strange that you are so worried about >> the microsecond or so extra reading time it takes to recognize an >> all-caps word, based on the "shape of the word" model, yet are prepared >> to pay this enormous cost

Re: [Python-ideas] loop: statement

See my post a month ago (29 September) in the archive with links to some related discussions. Subject "while: for the loop". (I don't have access to the archive now so I can't link to the post) One proposal was exactly about the "loop" keyword:

[Python-ideas] Off-topic: can't access mail.python.org

Sorry for posting it here on the list, but I don't know the right contact for technical questions. The problem is, for 3 weeks or so the mail.python.org site is not accessible for me. What can be causing this? This means I can't manage the mail delivery, subscribe or unsubscribe or open any mail

Re: [Python-ideas] f-string "debug" conversion

On Wed, Oct 3, 2018 at 3:28 AM Eric V. Smith wrote: > > Here’s the idea: for f-strings, we add a !d conversion operator, which > is superficially similar to !s, !r, and !a. The meaning of !d is: > produce the text of the expression (not its value!), followed by an > equal sign, followed by the

Re: [Python-ideas] "while:" for the loop

I put the list of related discussion here, just in case. Same suggestion: https://mail.python.org/pipermail/python-dev/2005-July/054914.html Idea for the "loop" keyword: https://mail.python.org/pipermail/python-ideas/2014-June/028202.html (followed by the same suggestion from @Random832:

Re: [Python-ideas] "while:" for the loop

On Wed, Sep 26, 2018 at 4:46 PM Mark E. Haase wrote: > > On Tue, Sep 25, 2018 at 8:47 PM Mikhail V wrote: >> >> As for statistics - IIRC someone gave statistics once, but the only >> thing I can remember [...] "while 1/True" is used quite a lot in the > &g

Re: [Python-ideas] "while:" for the loop

On Wed, Sep 26, 2018 at 5:38 AM Chris Angelico wrote: > > > I like saying while "something": where the string describes the loop's > real condition. For instance, while "moar data": if reading from a > socket, or while "not KeyboardInterrupt": if the loop is meant to be > halted by SIGINT. > >

[Python-ideas] "while:" for the loop

I suggest allowing "while:" syntax for the infinite loop. I.e. instead of "while 1:" and "while True:" notations. IIRC, in the past this was mentioned in python-list discussions as alternative for the "while True:"/"while 1:" syntax. I even had impression that there was nothing rational against

Re: [Python-ideas] Moving to another forum system where moderation is possible

On Thu, Sep 20, 2018 at 11:21 AM Cameron Simpson wrote: > > On 20Sep2018 10:16, Chris Barker - NOAA Federal wrote: > >Let's just keep it on email -- I, at least, find i never participate in any > >other type of discussion forum regularly. > > As do I. Email comes to me. Forums, leaving aside

Re: [Python-ideas] Moving to another forum system where

On Wed, Sep 19, 2018 at 7:49 AM Franklin? Lee wrote: > > On Tue, Sep 18, 2018 at 8:21 PM James Lu wrote: > > > > > Is that really an issue here? I personally haven't seen threads where > > > Brett tried to stop an active discussion, but people ignored him and > > > kept fighting. > > Not

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

On Thu, Sep 13, 2018 at 11:39 AM Samantha Quan wrote: > > One alternative to that clause I could think of is "Clean is better than > dirty", > but please do speak up if you have better ideas. "Clean is better than hairy!" :-D > I ask you to give this change serious consideration, On a

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

On Thu, Jul 26, 2018 at 5:10 AM, Steven D'Aprano wrote: > On Wed, Jul 25, 2018 at 05:11:08PM -0500, 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

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

I personally do almost only classical programming, and I am somewhat opposed to OOP in general. So here my somewhat outlandish view, (and I am biased becase I will probably never need this feature). First thoughts after reading the PEP: what is so super-special and fundamental about None value?

Re: [Python-ideas] Alternative spelling for list.append()

On Tue, Jun 19, 2018 at 3:52 AM, Juancarlo Añez wrote: > >> The idea is to introduce new syntax for the list.append() method. >> >> >> Syntax: >> >> Variant 1. >> Use special case of index, namely omitted index: >> >> mylist[] = item > > > For all practical purpose, it would be enough to

Re: [Python-ideas] Alternative spelling for list.append()

On Mon, Jun 18, 2018 at 11:43 PM, Michael Selik wrote: > On Mon, Jun 18, 2018 at 12:56 PM Mikhail V wrote: >> >> Numpy arrays have also append() and insert() methods, > > In [2]: np.arange(1).append(2) > AttributeError: 'numpy.ndarray' object has no attribute 'append' &

Re: [Python-ideas] Alternative spelling for list.append()

On Mon, Jun 18, 2018 at 4:12 AM, Chris Angelico wrote: > On Mon, Jun 18, 2018 at 10:50 AM, Steven D'Aprano wrote: items[-0:] # failed parallel > ['spam', 'ham', 'foo', 'bar', 'quux'] > > So you use -1 in slices to parallel 1 (unlike using ~1 as with > indexing), and everything works

[Python-ideas] Alternative spelling for list.append()

[by request I've made new subject and summary of proposal] The idea is to introduce new syntax for the list.append() method. Syntax: Variant 1. Use special case of index, namely omitted index: mylist[] = item Examples: mylist = [1, 2, 3]--> [1, 2, 3] mylist[] = x

Re: [Python-ideas] Operator for inserting an element into a list

On Sun, Jun 17, 2018 at 2:52 AM, Steven D'Aprano wrote: > On Sat, Jun 16, 2018 at 08:21:42PM +0300, Mikhail V wrote: > >> By L[] there is some mnemonical hint because [] is used to create >> new empty list. > > How is that a hint? What is the connection between "

Re: [Python-ideas] Operator for inserting an element into a list

On Sat, Jun 16, 2018 at 4:44 AM, Cameron Simpson wrote: > On 16Jun2018 02:42, Mikhail V wrote: >> > Some things _should_ be syntax errors. Particularly things which may be > typing errors. Suppose I'd meant to type: > > L[0] = item > > Silent breakage, requiring r

Re: [Python-ideas] Operator for inserting an element into a list

sly I am starting to get tired of that style of conversation. I provided you links - you are not pleased again. > > On Fri, Jun 15, 2018, 5:40 PM Mikhail V wrote: >> >> On Sat, Jun 16, 2018 at 3:26 AM, Michael Selik wrote: >> > >> > >> > On Fri,

Re: [Python-ideas] Operator for inserting an element into a list

On Sat, Jun 16, 2018 at 3:26 AM, Michael Selik wrote: > > > On Fri, Jun 15, 2018, 5:24 PM Mikhail V wrote: >> >> there is just nothing against append() method. > > > Then why break the Zen: there should be only one obvious way? I think the question could be appl

Re: [Python-ideas] Operator for inserting an element into a list

On Sat, Jun 16, 2018 at 3:02 AM, Chris Angelico wrote: > On Sat, Jun 16, 2018 at 9:42 AM, Mikhail V wrote: >> Now I have slightly different idea. How is about special-casing of this >> as a shortcut for append: >> >> L[] = item >> >> Namely just use the f

Re: [Python-ideas] Operator for inserting an element into a list

Now I have slightly different idea. How is about special-casing of this as a shortcut for append: L[] = item Namely just use the fact that empty slice is SyntaxError now. I understand this is totally different approach than operator overloading and maybe hard to implement, but I feel like it

Re: [Python-ideas] Operator for inserting an element into a list

On Fri, Jun 15, 2018 at 6:54 PM, Chris Angelico wrote: > On Sat, Jun 16, 2018 at 1:48 AM, Mikhail V wrote: >> On Fri, Jun 15, 2018 at 5:51 AM, Michael Selik wrote: >> >>> If you would like to prove the need for this operator, one piece of evidence >>> you can

Re: [Python-ideas] Operator for inserting an element into a list

On Fri, Jun 15, 2018 at 5:51 AM, Michael Selik wrote: > If you would like to prove the need for this operator, one piece of evidence > you can provide is a count of the number of times someone writes > "list.append" for an iterable vs "+=" and encloses a str or other type in a > throw-away list

Re: [Python-ideas] Operator for inserting an element into a list

On Fri, Jun 15, 2018 at 1:04 AM, Michael Selik wrote: [..] > In case I need to clarify: > 1. You're duplicating current clear and more flexible syntax. > 2. Your proposed operators are confusing when compared with their meanings > elsewhere. what haven't we repeated in this thread yet?

Re: [Python-ideas] Operator for inserting an element into a list

On Thu, Jun 14, 2018 at 2:58 AM, Greg Ewing wrote: > Mikhail V wrote: >> >> L ^= item >> is >> L.append(item) >> or >> L += [item] > > > Okay, that achieves an in-place append, but it's not exactly > obvious to the unenlightened what it does, whe

Re: [Python-ideas] Operator for inserting an element into a list

On Wed, Jun 13, 2018 at 5:46 PM, Chris Angelico wrote: > On Thu, Jun 14, 2018 at 12:40 AM, Mikhail V wrote: >> L1 = L2 ^ item >> is >> L1 = L2 + [item] >> >> and >> L ^= item >> is >> L.append(item) >> or >> L += [item] > &g

Re: [Python-ideas] Operator for inserting an element into a list

On Wed, Jun 13, 2018 at 5:13 PM, Chris Angelico wrote: > On Thu, Jun 14, 2018 at 12:04 AM, Mikhail V wrote: >> On Wed, Jun 13, 2018 at 2:15 AM, Greg Ewing >> wrote: >>> Mikhail V wrote: >> Sorry for repeating myself, the idea was that the default meaning i

Re: [Python-ideas] Operator for inserting an element into a list

On Wed, Jun 13, 2018 at 2:15 AM, Greg Ewing wrote: > Mikhail V wrote: >> > My feeling is that inserting is not a frequent enough operation > to warrant having its own operator, especially not when there > is already a syntax that does the same thing. Depends on what yo

Re: [Python-ideas] Operator for inserting an element into a list

On Tue, Jun 12, 2018 at 10:25 PM, Michael Selik wrote: > On Tue, Jun 12, 2018 at 11:08 AM Mikhail V wrote: >> >> On Tue, Jun 12, 2018 at 7:42 PM, Clint Hepner >> wrote: >> >> So the idea was about an insert/append operator. >> Which would u

Re: [Python-ideas] Operator for inserting an element into a list

On Tue, Jun 12, 2018 at 7:42 PM, Clint Hepner wrote: > >> On 2018 Jun 12 , at 10:54 a, Mikhail V wrote: >> >> I think it would be logical to have the insert operator for lists. >> Similar to list extend operator += , it could use one of augmented >> assignme

Re: [Python-ideas] Operator for inserting an element into a list

On Tue, Jun 12, 2018 at 5:54 PM, Mikhail V wrote: > I think it would be logical to have the insert operator for lists. > Similar to list extend operator += , it could use one of augmented > assignment operators, e,g, /=. > > L = ["aa"] > > L[0] /= "bb&q

[Python-ideas] Operator for inserting an element into a list

I think it would be logical to have the insert operator for lists. Similar to list extend operator += , it could use one of augmented assignment operators, e,g, /=. L = ["aa"] L[0] /= "bb" -> ["bb", "aa"] L[0] /= [1,2] -> [[1,2], "aa"] etc. Without index it would work

Re: [Python-ideas] Inline assignments using "given" clauses

On Fri, May 4, 2018 at 3:06 PM, Nick Coghlan wrote: > > With that spelling, the three examples above would become: > > # Exactly one branch is executed here > if m given m = pattern.search(data): > ... > elif m given m = other_pattern.search(data)): >

Re: [Python-ideas] Objectively Quantifying Readability

On Wed, May 2, 2018 at 4:03 AM, Matt Arcidy <marc...@gmail.com> wrote: > On Tue, May 1, 2018 at 5:35 PM, Mikhail V <mikhail...@gmail.com> wrote: > >> to be pedantic - ReallyLongDescriptiveIdentifierNames >> has also an issue with "I" which might confuse be

Re: [Python-ideas] Objectively Quantifying Readability

On Tue, May 1, 2018 at 6:04 PM, Jacco van Dorp wrote: > 2018-05-01 14:54 GMT+02:00 Greg Ewing : >> Rhodri James wrote: >>> >>> I'd be interested to know if there is a readability difference between >>> really_long_descriptive_identifier_name and

Re: [Python-ideas] Objectively Quantifying Readability

On Tue, May 1, 2018 at 3:42 AM, Steven D'Aprano wrote: > On Mon, Apr 30, 2018 at 11:28:17AM -0700, Matt Arcidy wrote: > > - people are not good judges of readability; People are the only judges of readability. Just need the right people.

Re: [Python-ideas] A "local" pseudo-function

On Sun, Apr 29, 2018 at 7:22 PM, Mikhail V <mikhail...@gmail.com> wrote: > On Sun, Apr 29, 2018 at 3:30 AM, Tim Peters <tim.pet...@gmail.com> wrote: > >> Time to note another subtlety: people don't _really_ want "a new >> scope" in Python.

Re: [Python-ideas] A "local" pseudo-function

On Sun, Apr 29, 2018 at 3:30 AM, Tim Peters wrote: > > """ > Time to note another subtlety: people don't _really_ want "a new > scope" in Python. If they did, then _every_ name appearing in a > binding context (assignment statement target, `for` target, ...) for > the

Re: [Python-ideas] Spelling of Assignment Expressions PEP 572 (was post #4)

On Tue, Apr 17, 2018 at 6:09 AM, Thautwarm Zhao wrote: > > > 3) "target ? expr" (where ? is some other word/character - IIRC > > "target from expr" was proposed once) > > A more popular convention is to mark `?` as handling boolean variables, so > `target ? expr`

Re: [Python-ideas] Spelling of Assignment Expressions PEP 572 (was post #4)

On Sun, Apr 15, 2018 at 6:58 PM, Steven D'Aprano wrote: > On Sun, Apr 15, 2018 at 10:21:02PM +1000, Chris Angelico wrote: > >> I don't think we're ever going to unify everyone on an arbitrary >> question of "expression first" or "name first". But to all the >> "expression

Re: [Python-ideas] Spelling of Assignment Expressions PEP 572 (was post #4)

On Sun, Apr 15, 2018 at 2:01 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 15 April 2018 at 19:41, Mikhail V <mikhail...@gmail.com> wrote: >> So IIUC, the *only* reason is to avoid '==' ad '=' similarity? >> If so, then it does not sound convincing at all. >>

Re: [Python-ideas] Spelling of Assignment Expressions PEP 572 (was post #4)

On Sun, Apr 15, 2018 at 12:19 PM, Kirill Balunov wrote: > > > 2018-04-15 6:08 GMT+03:00 Nick Coghlan : >> >> > >> >> P.S. The pros and cons of the current syntax proposals, as I see them: >> >> === Expression first, 'as' keyword === >> >> while

Re: [Python-ideas] Syntax idea for 2D lists\arrays

On Thu, Mar 15, 2018 at 6:15 AM, Steven D'Aprano <st...@pearwood.info> wrote: > On Thu, Mar 15, 2018 at 01:32:35AM +0100, Mikhail V wrote: > > > Using spaces to separate items has the fatal flaw that it cannot > distinguish > > x - y 0 # two items, the expressio

Re: [Python-ideas] Syntax idea for 2D lists\arrays

On Thu, Mar 15, 2018 at 6:15 AM, Steven D'Aprano <st...@pearwood.info> wrote: > On Thu, Mar 15, 2018 at 01:32:35AM +0100, Mikhail V wrote: > > Using spaces to separate items has the fatal flaw that it cannot > distinguish > > x - y 0 # two items, the expression `

Re: [Python-ideas] Syntax idea for 2D lists\arrays

On Thu, Mar 15, 2018 at 2:10 AM, Terry Reedy <tjre...@udel.edu> wrote: > On 3/14/2018 8:32 PM, Mikhail V wrote: >> >> ... >> >> Also in 1d case one might omit the line continuation \: >> >> L ===* >> "msg1" >>

[Python-ideas] Syntax idea for 2D lists\arrays

Once there was a discussion about alternative list and arrays creation and assignment syntaxes. I think this is one of things with room for ideas and has frequent usage. I've had some ideas for syntax long ago, and now I remembered it because of the recent topic "Descouraging the implicit string

Re: [Python-ideas] Allow additional separator character in variables

Just for the record, there is also another hyphen, called "soft hyphen", U+00AD. Main difference is that in some software it is an 'interpreted' symbol, and thus may simply disappear from the screen in such software, so it cannot be surely defined as a printable character. OTOH the benefit is that

Re: [Python-ideas] Allow additional separator character in variables

On Thu, Nov 23, 2017 at 4:46 AM, Nick Coghlan wrote: > On 21 November 2017 at 21:55, Stephen J. Turnbull > wrote: >> >> Personally, I think that Python probably should ban non-ASCII >> non-letter characters in identifiers and whitespace,

Re: [Python-ideas] Allow additional separator character in variables

Serhiy Storchaka wrote: > Yes, it causes less confusion that changing meaning of a minus. If those chars are not used at all, then yes :) And I don't recall I was exactly propsing changing meaning of minus > But the name моязмінна doesn't cause any confusion if used in an > appropriate context

Re: [Python-ideas] Allow additional separator character in variables

On Tue, Nov 21, 2017 at 2:51 AM, Stephen J. Turnbull <turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Mikhail V writes: > > > On Mon, Nov 20, 2017 at 5:46 AM, Guido van Rossum <gu...@python.org> wrote: > > > Please kill this thread. > > > > So the i

Re: [Python-ideas] Allow additional separator character in variables

On Mon, Nov 20, 2017 at 5:46 AM, Guido van Rossum wrote: > Please kill this thread. So the idea is too bad? ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct:

Re: [Python-ideas] Allow additional separator character in variables

come on, probably you also want study for emoticons as a separators? On Sun, Nov 19, 2017 at 5:16 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 19 November 2017 at 13:22, Mikhail V <mikhail...@gmail.com> wrote: >> For me, one "cheap" solution against undersco

Re: [Python-ideas] Allow additional separator character in variables

On Sun, Nov 19, 2017 at 5:16 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 19 November 2017 at 13:22, Mikhail V <mikhail...@gmail.com> wrote: >> For me, one "cheap" solution against underscores is to use >> syntax highlighting which grays them ou

Re: [Python-ideas] Allow additional separator character in variables

On Sun, Nov 19, 2017 at 3:42 AM, Nick Coghlan wrote: > For anyone tempted to suggest "What about multiple underscores > indicating continuation of the variable name?", that's still a > compatibility problem due to the unary minus operator: > > >>> my--variable > 2 >

Re: [Python-ideas] Allow additional separator character in variables

Chris A wrote: > Both of these create extremely confusing situations, where two > nearly-identical symbols have completely different meanings. In reality, hyphen and Minus sign are not even closely similar - Minus is ca. twice as wide, however the citizens of the Monospaced Kingdom may disagree ;

[Python-ideas] Allow additional separator character in variables

Python allows underscore character as a separator in variables. This is better than nothing, still it does not make the look much better. **Proposal**: allow additional separator, namely hyphen character. **Benefits**: this should provide significant readability improvement. Compared to most

[Python-ideas] A suggestion for a do...while loop

>All these situations could be handled by making a "while:" with no >condition act as "while True:" >But they could also be handled by updating pep8 to make "while True:" the >recommended infinite loop syntax and make linters smarter about this (if >they aren't already). There was a big related

Re: [Python-ideas] Allow function to return multiple values

On 26 June 2017 at 01:14, rym...@gmail.com wrote: > IIRC I'm pretty sure the OP just didn't know about the existence of tuple > unpacking and the ability to use that to return multiple values. > Can be so, though it was not quite clear. The original OP's example function

Re: [Python-ideas] Allow function to return multiple values

joannah nanjekye wrote: > [...] > >Today I was writing an example snippet for the book and needed to write a >function that returns two values something like this: > >def return_multiplevalues(num1, num2): > return num1, num2 > > I noticed that this actually returns a tuple of the values

[Python-ideas] π = math.pi

Greg Ewing wrote: >Steven D'Aprano wrote: >> There's not much, if any, benefit to writing: >> >> ∫(expression, lower_limit, upper_limit, name) >More generally, there's a kind of culture clash between mathematical >notation and programming notation. Mathematical notation tends to >almost

Re: [Python-ideas] More classical for-loop

On 18 February 2017 at 04:13, Joao S. O. Bueno wrote: > You can still use range. Yes thats what I do, see my proposal > I don't see the point in continuing this thread. How does this add to the syntax discussion? I was replying to Nicks quite vague comments which were

Re: [Python-ideas] More classical for-loop

A short Meta-note: I see most people are bottom-replying and still many do top-reply, namely you Nick always do. I dont know if there is a rule, but it makes quite hard to manage/read post with mixed posting style. On 17 February 2017 at 23:51, Nick Timkovich wrote: > >

Re: [Python-ideas] More classical for-loop

On 17 February 2017 at 04:59, Chris Angelico <ros...@gmail.com> wrote: > On Fri, Feb 17, 2017 at 2:13 PM, Mikhail V <mikhail...@gmail.com> wrote: > > Common use case: > > > > L = [1,3,5,7] > > > > for i over len(L): > >e = L[i] > &

[Python-ideas] More classical for-loop

Here is a summary of my idea about for-loop. It focuses on readability and does not take in account possible technical nuances. This is my first attempt to write a full proposal and I suppose it is ok to post it here. Many things (readability) can raise opinion based dispute, so it is sort of my

Re: [Python-ideas] Contraction for "for x in range()"

On 15 February 2017 at 00:41, Nick Timkovich wrote: > Make some shim object that you can index into to get that functionality, > could even call it Z (for the set of all integers). Short, and requires no > new syntax. > > class IndexableRange: > def __getitem__(self,

Re: [Python-ideas] Contraction for "for x in range()"

On 14 February 2017 at 22:41, MRAB <pyt...@mrabarnett.plus.com> wrote: > On 2017-02-14 21:09, Zachary Ware wrote: > >> On Tue, Feb 14, 2017 at 3:06 PM, Mikhail V <mikhail...@gmail.com> wrote: >> >>> I have a small syntax idea. >>> In sh

[Python-ideas] Contraction for "for x in range()"

I have a small syntax idea. In short, contraction of for x in range(a,b,c) : to for x in a,b,c : I really think there is something cute in it. So like a shortcut for range() which works only in for-in statement. So from syntactical POV, do you find it nice syntax? Visually it seems to me less

Re: [Python-ideas] A more readable way to nest functions

On 30 January 2017 at 21:25, David Mertz <me...@gnosis.cx> wrote: > On Mon, Jan 30, 2017 at 11:52 AM, Mikhail V <mikhail...@gmail.com> wrote: > >> *Theoretically* I see a solution by 'inlined' statements. >> Take a long example: >> >> p

Re: [Python-ideas] Python Reviewed

On 9 January 2017 at 12:25, Simon Lovell wrote: > Python Reviewed > > The Good : > ... > The Bad: > ... I agree with many points, but: > No end required for if/while/for blocks. .. Makes the code less readable Nope, it makes code significantly better readable. I'm sort

Re: [Python-ideas] Input characters in strings by decimals (Was: Proposal for default character representation)

On 8 December 2016 at 17:52, Chris Angelico wrote: > In the first place, many people have pointed out to you that Unicode > *is* laid out best in hexadecimal. Ok if it is aligned intentionally on binary grid obviously hex numbers will show some patterns, but who argues? And

Re: [Python-ideas] Input characters in strings by decimals (Was: Proposal for default character representation)

On 8 December 2016 at 15:46, Alexandre Brault wrote: >>> Can you cite some examples of Unicode reference tables I can look up a >>> decimal number in? They seem rare; perhaps in a list as a secondary column, >>> but they're not organized/grouped decimally. Readability

Re: [Python-ideas] Input characters in strings by decimals (Was: Proposal for default character representation)

On 8 December 2016 at 03:32, Matthias welp wrote: > Dear Mikhail, > > With python3.6 you can use format strings to get very close to your > desired behaviour: > > f"{48:c}" == "0" > f"{:c}" == chr() > > It works with variables too: > > charvalue = 48 >

Re: [Python-ideas] Input characters in strings by decimals (Was: Proposal for default character representation)

On 8 December 2016 at 03:36, Alexander Belopolsky <alexander.belopol...@gmail.com> wrote: > > On Wed, Dec 7, 2016 at 9:07 PM, Mikhail V <mikhail...@gmail.com> wrote: >> >> it somehow settled in >> peoples' minds that hex reference should be preferred, f

Re: [Python-ideas] Input characters in strings by decimals (Was: Proposal for default character representation)

On 8 December 2016 at 01:57, Nick Timkovich wrote: >> hex notation not so readable and anyway decimal is kind of standard way to >> represent numbers > > > Can you cite some examples of Unicode reference tables I can look up a > decimal number in? They seem rare; perhaps

Re: [Python-ideas] Input characters in strings by decimals (Was: Proposal for default character representation)

On 8 December 2016 at 01:13, Nick Timkovich wrote: > Out of curiosity, why do you prefer decimal values to refer to Unicode code > points? Most references, http://unicode.org/charts/PDF/U0400.pdf (official) > or

[Python-ideas] Input characters in strings by decimals (Was: Proposal for default character representation)

In past discussion about inputing and printing characters, I was proposing decimal notation instead of hex. Since the discussion was lost in off-topic talks, I'll try to summarise my idea better. I use ASCII only for code input (there are good reasons for that). Here I'll use Python 3.6, and

Re: [Python-ideas] Technical possibilities for a syntax [was: Reverse assignment operators ...]

On 18 November 2016 at 01:26, Steven D'Aprano wrote: > At this point, I think it is a waste of time to continue discussing > alternatives to augmented assignment syntax. I'm happy to discuss the > culture of Python and how we decide on making changes to the language, > but I

Re: [Python-ideas] Technical possibilities for a syntax [was: Reverse assignment operators ...]

On 16 November 2016 at 18:28, Paul Moore wrote: > No I don't think you're an idiot. I thought you were offering a proposal. > >> When I was writing that I just thought, should I make a special note >> that I am making it only for example, but then thought, oh that would >> be

[Python-ideas] Technical possibilities for a syntax [was: Reverse assignment operators ...]

On 15 November 2016 at 10:46, Paul Moore wrote: > If you're proposing a = a + b to introspect at runtime the type of a, > and produce different bytecode depending on the answer, you're > proposing a fundamental change to the runtime semantics of Python > (such that the

Re: [Python-ideas] How we think about change [was: Reverse assignment operators...]

On 15 November 2016 at 14:04, Stephen J. Turnbull <turnbull.stephen...@u.tsukuba.ac.jp> wrote: > > Mikhail V writes: > > But how do you jump to lists already? > Thus, in explaining this kind of thing it is often useful > (YMMV) to "jump" to a different ty

Re: [Python-ideas] Reverse assignment operators (=+, =-, =*, =/, =//, =**, =%)

On 14 November 2016 at 21:52, Todd wrote: >> I can understand you good. But imagine, if Numpy would allow you to >> simply write: >> A = A + 1 >> Which would bring you directly to same internal procedure as A += 1. >> So it does not currently, why? > > > First, because the

Re: [Python-ideas] Reverse assignment operators (=+, =-, =*, =/, =//, =**, =%)

On 14 November 2016 at 19:57, Nick Timkovich wrote: > Currently, Numpy takes advantage of __iadd__ and friends by performing the > operation in-place; there is no copying or other object created. Numpy is > very thinly C, for better and worse (which is also likely where

Re: [Python-ideas] Reverse assignment operators (=+, =-, =*, =/, =//, =**, =%)

On 14 November 2016 at 12:16, Steven D'Aprano <st...@pearwood.info> wrote: > On Mon, Nov 14, 2016 at 01:19:30AM +0100, Mikhail V wrote: > > [...] >> >> A good syntax example: >> >> >> >> a = sum (a, c) > > There is a reason why mathemati

Re: [Python-ideas] Reverse assignment operators (=+, =-, =*, =/, =//, =**, =%)

On 12 November 2016 at 21:08, João Matos wrote: > What I would like to propose is the creation of the reverse: > a =+ c is the same as a = c + a > a =- c is the same as a = c - a > a =* c is the same as a = c * a > a =/ c is the same as a = c / a > a =// c is the same as a =

Re: [Python-ideas] Alternative to PEP 532: delayed evaluation of expressions

On 7 November 2016 at 02:32, Nathaniel Smith wrote: > On Sun, Nov 6, 2016 at 5:06 AM, Eric V. Smith wrote: >> Creating a new thread, instead of hijacking the PEP 532 discussion. >> >> From PEP 532: >> >>> Abstract >>> >>> >>> Inspired by PEP 335, PEP

Re: [Python-ideas] Null coalescing operator

On 2 November 2016 at 21:50, David Mertz <me...@gnosis.cx> wrote: > Even though I really don't want new null-coalescing operators, I really > appreciate the ternary operator in Python (or in C). > > On Wed, Nov 2, 2016 at 12:38 PM, Mikhail V <mikhail...@gmail.com> wrote:

Re: [Python-ideas] Null coalescing operator

On 2 November 2016 at 19:34, MRAB wrote: > How about borrowing from C: > > target = expr1 || expr2 || expr3 > target = expr1 && expr2 && expr3 > > except that only None would be considered falsey? > > Or would that be confusing? Sorry for intruding into

Re: [Python-ideas] More user-friendly version for string.translate()

On 27 October 2016 at 00:17, Chris Barker wrote: > 1) an easy way to spell "remove all the characters other than these" > > I think that's a good idea. What with unicode having an enormous number > of code points, it really does make sense to have a way to specify > only

Re: [Python-ideas] Non-ASCII in Python syntax? [was: Null coalescing operator]

Steven D'Aprano wrote: > I cannot wait for the day that we can use non-ASCII operators. But I > don't think that day has come: it is still too hard for many people > (including me) to generate non-ASCII characters at the keyboard, and > font support for some of the more useful ones are still

  1   2   >