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 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
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 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 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
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 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
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
>
>
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, 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
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
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
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
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 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
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 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
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
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
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
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
Hello all,
I want to share my thoughts about syntax improvements regarding
character representation in Python.
I am new to the list so if such a discussion or a PEP exists already,
please let me know.
So in short:
Currently Python uses hexadecimal notation
for characters for input and output.
Fo
Forgot to reply to all, duping my mesage...
On 12 October 2016 at 23:48, M.-A. Lemburg wrote:
> Hmm, in Python3, I get:
>
s = "абв.txt"
s
> 'абв.txt'
I posted output with Python2 and Windows 7
BTW , In Windows 10 'print' won't work in cmd console at all by default
with unicode but th
On 12 October 2016 at 23:58, Danilo J. S. Bellini
wrote:
> Decimal notation is hardly
> readable when we're dealing with stuff designed in base 2 (e.g. due to the
> visual separation of distinct bytes).
Hmm what keeps you from separateting the logical units to be represented each
by a decimal nu
On 12 October 2016 at 23:50, Thomas Nyberg wrote:
> Since when was decimal notation "standard"?
Depends on what planet do you live. I live on planet Earth. And you?
> opposite. For unicode representations, byte notation seems standard.
How does this make it a good idea?
Consider unicode table as
On 13 October 2016 at 01:50, Chris Angelico wrote:
> On Thu, Oct 13, 2016 at 10:09 AM, Mikhail V wrote:
>> On 12 October 2016 at 23:58, Danilo J. S. Bellini
>> wrote:
>>
>>> Decimal notation is hardly
>>> readable when we're dealing with stuff de
On 13 October 2016 at 04:18, Brendan Barnwell wrote:
> On 2016-10-12 18:56, Mikhail V wrote:
>>
>> Please don't mix the readability and personal habit, which previuos
>> repliers seems to do as well. Those two things has nothing
>> to do with each other.
>
&g
On 13 October 2016 at 04:49, Emanuel Barry wrote:
>> From: Mikhail V
>> Sent: Wednesday, October 12, 2016 9:57 PM
>> Subject: Re: [Python-ideas] Proposal for default character representation
>
> Hello, and welcome to Python-ideas, where only a small portion of ideas go
&
On 13 October 2016 at 08:02, Greg Ewing wrote:
> Mikhail V wrote:
>>
>> Consider unicode table as an array with glyphs.
>
>
> You mean like this one?
>
> http://unicode-table.com/en/
>
> Unless I've miscounted, that one has the characters
> arrang
Greg Ewing wrote:
> #define O_RDONLY0x /* open for reading only */
> #define O_WRONLY0x0001 /* open for writing only */
> #define O_RDWR 0x0002 /* open for reading and writing */
> #define O_ACCMODE 0x0003 /* mask for above mod
On 13 October 2016 at 10:18, M.-A. Lemburg wrote:
> I suppose you did not intend everyone to have to write
> \u010 just to get a newline code point to avoid the
> ambiguity.
Ok there are different usage cases.
So in short without going into detail,
for example if I need to type in a unicode
On 13 October 2016 at 12:05, Cory Benfield wrote:
>
> integer & 0x00FF # Hex
> integer & 16777215 # Decimal
> integer & 0o # Octal
> integer & 0b # Binary
>
> The octal representation is infuriating because one octal digit refers to
> *three* bits
Correct,
On 13 October 2016 at 16:50, Chris Angelico wrote:
> On Fri, Oct 14, 2016 at 1:25 AM, Steven D'Aprano wrote:
>> On Thu, Oct 13, 2016 at 03:56:59AM +0200, Mikhail V wrote:
>>> and in long perspective when the world's alphabetical garbage will
>>> dissapea
On 14 October 2016 at 11:36, Greg Ewing wrote:
>but bash wasn't designed for that.
>(The fact that some people use it that way says more
>about their dogged persistence in the face of
>adversity than it does about bash.)
I can not judge what bash is good for, since I never
tried to learn it. But
On 15 October 2016 at 16:27, Chris Angelico wrote:
> On Sun, Oct 16, 2016 at 12:06 AM, Mikhail V wrote:
>> But I can bravely claim that it is better than *any*
>> hex notation, it just follows from what I have here
>> on paper on my table, namely that it is physically
>
On 16 October 2016 at 02:58, Greg Ewing wrote:
>> even if it is assembler or whatever,
>> it can be made readable without much effort.
>
>
> You seem to be focused on a very narrow aspect of
> readability, i.e. fine details of individual character
> glyphs. That's not what we mean when we talk ab
On 16 October 2016 at 17:16, Todd wrote:
>Even if you were right that your approach is somehow inherently easier,
>it is flat-out wrong that other approaches lead to "brain impairment".
>On the contrary, it is well-established that challenging
>the brain prevents or at least delays brain impairmen
On 16 October 2016 at 04:10, Steve Dower wrote:
>> I posted output with Python2 and Windows 7
>> BTW , In Windows 10 'print' won't work in cmd console at all by default
>> with unicode but thats another story, let us not go into that.
>> I think you get my idea right, it is not only about printin
On 16 October 2016 at 23:23, Greg Ewing wrote:
>> Those things cannot be easiliy measured, if at all,
>If you can't measure something, you can't be sure
>it exists at all.
What do you mean I can't be sure?
I am fully functional, mentally healthy man :)
>Have you *measured* anything, though? Do
On 17 October 2016 at 02:23, Steven D'Aprano wrote:
> On Sun, Oct 16, 2016 at 05:02:49PM +0200, Mikhail V wrote:
>
>> In this discussion yes, but layout aspects can be also
>> improved and I suppose special purpose of
>> language does not always dictate the layout of
On 19 October 2016 at 21:08, Todd wrote:
>
> a = np.ndarray(48, 11, 141, 13, -60, -37, 58, -52, -29, 134],
> [-6, 96, -66, 137, -59, -147, -118, -104, -123, -7]],
> [[-103, 50, -89, -12, 28, -12, 119, -131, -73, 21],
> [-58, 105, 25, -138,
Hello all,
I would be happy to see a somewhat more general and user friendly
version of string.translate function.
It could work this way:
string.newtranslate(file_with_table, Drop=True, Dec=True)
So the parameters:
1. "file_with_table" : a text file with table in following format:
#[In][Ou
On 24 October 2016 at 20:02, Chris Barker wrote:
> On Mon, Oct 24, 2016 at 10:50 AM, Ryan Birmingham
> wrote:
>>
>> I also believe that using a text file would not be the best solution;
>> using a dictionary,
>
>
> actually, now that you mention it -- .translate() already takes a dict, so
> if yo
On 24 October 2016 at 22:54, Chris Barker wrote:
> On Mon, Oct 24, 2016 at 1:30 PM, Mikhail V wrote:
>>
>> But how would you with current translate function drop all characters
>> that are not in the table?
>
>
> that is another question altogether, and one for a d
On 24 October 2016 at 23:10, Paul Moore wrote:
> On 24 October 2016 at 21:54, Chris Barker wrote:
>> I don't know a way to do "remove every character except these", but someone
>> I expect there is a way to do that efficiently with Python strings.
>
> It's easy enough with the re module:
>
r
On 25 October 2016 at 04:37, Steven D'Aprano wrote:
>> I would be happy to see a somewhat more general and user friendly
>> version of string.translate function.
>> It could work this way:
>> string.newtranslate(file_with_table, Drop=True, Dec=True)
> Mikhail, I appreciate that you have many ide
On 25 October 2016 at 19:10, Stephen J. Turnbull
wrote:
> So my previous thought on it was, that there could be set of such functions:
>
> str.translate_keep(table) - this is current translate, namely keeps
> non-defined chars untouched
> str.translate_drop(table) - all the same, but droppin
On 25 October 2016 at 23:50, Chris Barker wrote:
>that was kind of a throwaway comment,
>but I think it's a LONG way out, but ideally,
>the OWTDI would be "curly quotes". The fact that in ASCII,
>a single quote and a apostrophe are teh same,
>and that there is no distinction between opening
>and
On 26 October 2016 at 00:53, Mikhail V wrote:
> On 25 October 2016 at 23:50, Chris Barker wrote:
>
>>that was kind of a throwaway comment,
>>but I think it's a LONG way out, but ideally,
>>the OWTDI would be "curly quotes". The fact that in ASCII,
>>
On 26 October 2016 at 03:40, Steven D'Aprano wrote:
> in a "table.txt" file, and typing:
>
> {
> 123: 456,
> 124: 457,
> 125: 458,
> # two hundred more lines
> }
>
>
> in a "table.py" file? The difference is insignificant. And the Python
> version can be cleaned up:
>
Ok, you have opened my eyes
On 26 October 2016 at 20:58, Stephen J. Turnbull
wrote:
>import collections
>def translate_or_drop(string, table):
>"""
>string: a string to process
>table: a dict as accepted by str.translate
>"""
>return string.translate(collections.defaultdict(lambda: None, **table))
>All O
On 27 October 2016 at 01:13, Steven D'Aprano wrote:
> On Wed, Oct 26, 2016 at 03:37:54AM +0200, Mikhail V wrote:
>
>> Extended ASCII
>
> There are over 200 different, mutually incompatible, so-called
> "extended ASCII" code pages and encodings.
>
> And of
On 27 October 2016 at 00:17, Chris Barker wrote:
> I"ve lost track of what (If anything) is actually being proposed here... so
> I"m going to try a quick summary:
>
>
> 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
On 27 October 2016 at 03:51, Chris Barker wrote:
> On Wed, Oct 26, 2016 at 5:10 PM, Mikhail V wrote:
>>
>> 2) a table with characters that are reasonably valuable
>> and cover 99% of all programming, communication and typography in latin
>> script
>
>
> I th
On 27 October 2016 at 06:24, Chris Angelico wrote:
> Unicode is here to stay.
Congratulations. And chillax. I don't blog anywhere, have no time for that.
Mikhail
___
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/li
On 27 October 2016 at 06:24, Chris Angelico wrote:
> On Thu, Oct 27, 2016 at 2:06 PM, Mikhail V wrote:
>> Yep, double quotes , dashes and bullets are very valuable both for typography
>> and code (which to the largest part is the same)
>> So if just blank out
On 27 October 2016 at 21:40, Random832 wrote:
> On Thu, Oct 27, 2016, at 14:28, Mikhail V wrote:
>> So you need umlauts to describe an algorithm and to explain yourself in
>> turkish?
>> Cool story. Poor uncle Garamond spins in his coffin...
>
> Why do you need 26 lett
On 27 October 2016 at 21:51, M.-A. Lemburg wrote:
> On 27.10.2016 20:28, Mikhail V wrote:
>> So what about curly quotes? This would make at
>> least some sense, regardless of unicode.
>
> -1. This would break code using curly quotes in string literals,
> break existing
On 29 October 2016 at 18:19, Stephen J. Turnbull
wrote:
>> For better or worse, it may be emoji that drive that change ;-)
>>
>> I suspect that the 100 million or so Chinese, Japanese, Korean, and
>> Indian programmers who have had systems that have no trouble
>> whatsoever handling non-ASCII for
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 incon
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 what you >want, rather tha
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 discussion and off-topic again,
Su
On 2 November 2016 at 21:50, David Mertz 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 wrote:
>>
>> result = a > b ? x : y
&g
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 505, PEP 531, and the related discuss
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 = c // a
> a =% c is th
On 14 November 2016 at 00:08, Todd wrote:
>
> On Sun, Nov 13, 2016 at 4:00 PM, Mikhail V wrote:
>>
>> 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 =
On 14 November 2016 at 12:16, Steven D'Aprano 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 mathematicians and accountants
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 the +=
> syntax came from).
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 language doesn't allow
On 15 November 2016 at 00:34, Paul Moore wrote:
> On 14 November 2016 at 22:13, Mikhail V wrote:
>>> we don't want A = A + 1 to be the same as A += 1 "
>>
>> This sounds quite frustrating for me, what else could this be but A += 1?
>> Would I want a copy
On 15 November 2016 at 14:04, Stephen J. Turnbull
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 type that supports the same behavior
> to see
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 resulting language is arguab
On 16 November 2016 at 10:27, Paul Moore wrote:
> On 16 November 2016 at 08:51, Mikhail V wrote:
>> What semantics it will fundamentally break or so hard to implement?
>
> I'm afraid I don't have time at the moment to fully review your email,
> but my first impressi
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 too pedantic.
>
> Wel
On 17 November 2016 at 03:50, Stephen J. Turnbull
wrote:
> Matthias Bussoni writes:
>
> > Please be mindful when replying, even if some of the lurker know
> > who some of you are and can figure out that some of the reply to
> > this thread below this message are sarcastic, not all readers
> >
On 17 November 2016 at 10:22, Paul Moore wrote:
> On 17 November 2016 at 03:07, Stephen J. Turnbull
> wrote:
>> Paul Moore writes:
>>
>> > PS Note for anyone who wants to take this off on a wild tangent - my
>> > above comment is *in the context of Python as it has been defined for
>> > 20+ ye
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 am not interested in d
On 18 November 2016 at 01:26, Steven D'Aprano wrote:
Sorry, just for a second one more comment to your comment.
BTW, Steve, there is no any "battle", only peace and pleasure.
And exchange of knowledge and opinions of adult intelligents.
> Mikhail, you are missing the point that people have alre
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 Windo
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 https://en.wikibooks.org/wiki/Unicode/Character_reference/-0FFF ,
> prefer to refe
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
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 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 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 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 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 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 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 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 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 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 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 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
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 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) :
>
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
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 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)
> &
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 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
1 - 100 of 159 matches
Mail list logo
