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 simp
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
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")
Currentl
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-ide
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 for
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 the
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 = """
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
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.:
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 p
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:
https://mail.python.org/pipermail/python-ideas/2014-J
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 ar
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 rep
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:
https://
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
>
>
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.
>
> Chr
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
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 thei
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 personal
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 seri
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 concisen
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?
Is
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 defin
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
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 *except
[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
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 &qu
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, requir
ously 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
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
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
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 loo
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 pr
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 t
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? Motivation
On Thu, Jun 14, 2018 at 7:40 PM, Chris Barker wrote:
> On Wed, Jun 13, 2018 at 6:45 PM, Mikhail V wrote:
>>
> So it would be nice to have an operator version of append -- but given the
> limited number of operators, and their usual uses, I suspect it would cause
> even more co
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
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
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
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
On Tue, Jun 12, 2018 at 10:26 PM, Terry Reedy wrote:
> On 6/12/2018 10:54 AM, Mikhail V wrote:
>> Though additional brackets look really confusing for this purpose,
>> so I don't feel like using this seriously.
>
>
> Learning about lists means learning about slice as
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 use augmented
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
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
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 l
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)):
> ...
> else:
>
On Wed, May 2, 2018 at 4:03 AM, Matt Arcidy wrote:
> On Tue, May 1, 2018 at 5:35 PM, Mikhail V wrote:
>
>> to be pedantic - ReallyLongDescriptiveIdentifierNames
>> has also an issue with "I" which might confuse because it
>> looks same as little L. Just to illus
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
>>> ReallyLongDescriptiveIdentifierNames.
>>
>>
>> A
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.
___
Python-idea
On Sun, Apr 29, 2018 at 7:22 PM, Mikhail V wrote:
> 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
> If ther
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 duration would vanish when
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` could mean `expr if target el
On Mon, Apr 16, 2018 at 8:42 PM, Chris Angelico wrote:
> On Mon, Apr 16, 2018 at 11:05 PM, Mikhail V wrote:
>
> Here are the three most popular syntax options, and how each would be
> explained:
>
> 1) "target := expr" ==> It's exactly the same as other for
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 first" people, a question
On Sun, Apr 15, 2018 at 2:01 PM, Nick Coghlan wrote:
> On 15 April 2018 at 19:41, Mikhail V wrote:
>> So IIUC, the *only* reason is to avoid '==' ad '=' similarity?
>> If so, then it does not sound convincing at all.
>> Of course Python does me a favo
On Sun, Apr 15, 2018 at 7:15 PM, Steven D'Aprano wrote:
> On Sun, Apr 15, 2018 at 11:11:37PM +0800, Thautwarm Zhao wrote:
>
>> I think maybe we can use unicode characters like ≜ (\triangleq) and add the
>> support of unicode completion to python repl. The unicode completion of
>> editors or ides h
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 (read_next_item() as value) is not None:
>>
On Thu, Mar 15, 2018 at 6:15 AM, Steven D'Aprano 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 `x - y` and the intege
On Thu, Mar 15, 2018 at 6:15 AM, Steven D'Aprano 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 `x - y` and the integer 0
&
On Thu, Mar 15, 2018 at 2:10 AM, Terry Reedy wrote:
> On 3/14/2018 8:32 PM, Mikhail V wrote:
>>
>> ...
>>
>> Also in 1d case one might omit the line continuation \:
>>
>> L ===*
>> "msg1"
>> "msg2"
>> &q
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 co
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
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, and maybe add
>> them later in response to requests from na
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
On Tue, Nov 21, 2017 at 2:51 AM, Stephen J. Turnbull
wrote:
> Mikhail V writes:
>
> > On Mon, Nov 20, 2017 at 5:46 AM, Guido van Rossum wrote:
> > > Please kill this thread.
> >
> > So the idea is too bad?
>
> No, the idea is *not* bad, it's just n
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: http://python.org/ps
.
Oh come on, probably you also want study for emoticons as a separators?
On Sun, Nov 19, 2017 at 5:16 AM, Nick Coghlan wrote:
> On 19 November 2017 at 13:22, Mikhail V wrote:
>> For me, one "cheap" solution against underscores is to use
>> syntax highlighting whic
On Sun, Nov 19, 2017 at 5:16 AM, Nick Coghlan wrote:
> On 19 November 2017 at 13:22, Mikhail V wrote:
>> For me, one "cheap" solution against underscores is to use
>> syntax highlighting which grays them out, but if those become like
>> spaces, then it becomes a
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
> >>> my---variable
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 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 synt
>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 d
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 included same variables a
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 whic
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 exclu
On 19 February 2017 at 12:29, Steven D'Aprano wrote:
>
> Please tell us the optics formula used to determine the optical
> "goodness" and "badness" of a word. I want to see this physics formula
> that tells us how good or bad a word is "optically", and I want to know
> the names of at least a doze
On 19 February 2017 at 01:01, Erik wrote:
> On 18/02/17 19:35, Mikhail V wrote:
>>
>> You mean what my proposal would bring
>> technically better than e.g.:
>>
>> for i,e in enumerate(Seq)
>>
>> Well, nothing, and I will simply use it,
>> w
On 18 February 2017 at 05:43, Steven D'Aprano wrote:
> On Fri, Feb 17, 2017 at 06:31:19PM +0100, Mikhail V wrote:
>
>> I have said I need the index, probably you've misread my last comment.
>> Further more I explained why I think iteration over index should be the
&g
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 supposed to be critics.
>>
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:
>
> I think fundamentally by s
On 17 February 2017 at 18:40, Chris Angelico wrote:
> Further discussion probably should be redirected to python-list, but
> I'll elaborate here to explain why I do not support your proposal.
>
I don't see why you want redirect me to python-list, and how
exactly do you see it, start a related d
On 17 February 2017 at 17:37, Chris Angelico wrote:
> On Sat, Feb 18, 2017 at 3:30 AM, Mikhail V wrote:
> > On 17 February 2017 at 04:59, Chris Angelico wrote:
> >>
> >> On Fri, Feb 17, 2017 at 2:13 PM, Mikhail V
> wrote:
> >> > Common use case:
>
On 17 February 2017 at 04:59, Chris Angelico wrote:
> On Fri, Feb 17, 2017 at 2:13 PM, Mikhail V wrote:
> > Common use case:
> >
> > L = [1,3,5,7]
> >
> > for i over len(L):
> >e = L[i]
> >
> > or:
> >
> > length = len(L)
> &
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 op
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, item):
> if isins
On 14 February 2017 at 22:41, MRAB wrote:
> On 2017-02-14 21:09, Zachary Ware wrote:
>
>> On Tue, Feb 14, 2017 at 3:06 PM, Mikhail V wrote:
>>
>>> I have a small syntax idea.
>>> In short, contraction of
>>>
>>> for x in range(a,b,c) :
>
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 b
On 30 January 2017 at 21:25, David Mertz wrote:
> On Mon, Jan 30, 2017 at 11:52 AM, Mikhail V wrote:
>
>> *Theoretically* I see a solution by 'inlined' statements.
>> Take a long example:
>>
>> print ( merge (a, b, merge ( long_variable2, long_va
On 27 January 2017 at 22:07, Brent Brinkley wrote:
> HI Everyone,
>
> One issue that I’ve seen in a lot of languages struggle with is nested
> function calls.
>
Parenthesis when nested inherently create readability issues.
>
>
Yes there is such issue. I don't see however that a radical
change to
On 12 January 2017 at 20:09, Todd wrote:
>
> 4. I think either adding a bit more detail about the rationale for the
> decisions,
>
Would be nice. But then someone must tinker with it.
7. I am not sure what "Python will not use ``$`` as syntax." means. Are
> you referring to a particular commo
On 12 January 2017 at 03:37, Steven D'Aprano wrote:
> I have a proposal for an Informational PEP that lists things which will
> not change in Python. If accepted, it could be linked to from the signup
> page for the mailing list, and be the one obvious place to point
> newcomers to if they propos
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 of past master in such q
On 8 December 2016 at 19:45, Chris Angelico wrote:
> At the moment, you're showing
> minor advantages to decimal, and other people are showing minor
> advantages to hex; but IMO nothing yet has been strong enough to
> justify the implementation of a completely new way to do things -
> remember, p
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 to be fair, from my
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 counts, and
>>> introducing
On 8 December 2016 at 05:39, Random832 wrote:
> On Wed, Dec 7, 2016, at 22:06, Mikhail V wrote:
>> So you were catched up from the beginning with hex, as I see ;)
>> I on the contrary in dark times of learning programming
>> (that was C) always oriented myself on decimal code
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
> f"{charcvalue:c}" == chr(char
On 8 December 2016 at 03:36, Alexander Belopolsky
wrote:
>
> On Wed, Dec 7, 2016 at 9:07 PM, Mikhail V wrote:
>>
>> it somehow settled in
>> peoples' minds that hex reference should be preferred, for no solid reason
>> IMO.
>
> I may be showing my age
On 8 December 2016 at 01:52, MRAB wrote:
> On 2016-12-07 23:52, Mikhail V wrote:
...
>> =
>> Proposal: I would want to have a possibility to input it *by decimals*:
>>
>> s = "first cyrillic letters: \{1040}\{1041}\{1042}"
>> or:
>>
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 in a list as a secondary c
1 - 100 of 159 matches
Mail list logo
