Mikhail V wrote:
first Ethan said
it will be never implemented, and it turns out it has already
been implemented.
Only by accident -- I don't think anyone anticipated that
f-strings would be used that way!
--
Greg
___
Python-ideas mailing list
Python
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 codes
>> and don't regret
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 codes
> and don't regret it now.
C doesn't support decimal in string literals
On Wed, Dec 7, 2016 at 10:45 PM, Mikhail V wrote:
> Big big thanks, I didn't now this feature, but I have googled alot
> about "input characters as decimals" , so it is just added?
> Another evidence that Python rules!
Yes, f-strings are a new feature in Python 3.6, which is currently in
the rele
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, but all the facts that I remember about ASCI
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, but all the facts that I remember about ASCII
codes are in hex:
1. SPACE is 0x20 followed by punctuation symbols.
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(charvalue) # == "0"
This is only 1 character overhead + 1 character extra
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:
>> s = "first cyrillic letters: \(1040)\(1041)\(1042)"
>>
>>
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
>
> 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 column,
but they're not organized/grouped decimally. Readab
On 12/7/2016 7:22 PM, Mikhail V wrote:
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_re
On 2016-12-07 23:52, Mikhail V wrote:
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 th
On 12/07/2016 03:52 PM, Mikhail V wrote:
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.
While the discussion did range far and wide, one thing th
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
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 refer to them by hexadecimal as the planes and ranges are broken
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 07.12.2016 13:57, Nick Coghlan wrote:
> On 7 December 2016 at 18:33, M.-A. Lemburg wrote:
>> I know that you started this thread focusing on the stdlib,
>> but for the purpose of distributors, the scope goes far
>> beyond just the stdlib.
>>
>> Basically any Python module or package which the d
Nick Coghlan writes:
> While upstream changes turned out not to be necessary for the
> "distributor breaking up the standard library" use case, they may
> still prove worthwhile in making import errors more informative in the
> case of "I just built my own Python from upstream sources and didn
On 7 December 2016 at 18:33, M.-A. Lemburg wrote:
> I know that you started this thread focusing on the stdlib,
> but for the purpose of distributors, the scope goes far
> beyond just the stdlib.
>
> Basically any Python module or package which the distribution can
> provide should be usable as ba
I know that you started this thread focusing on the stdlib,
but for the purpose of distributors, the scope goes far
beyond just the stdlib.
Basically any Python module or package which the distribution can
provide should be usable as basis for a nice error message pointing to
the package to instal
21 matches
Mail list logo