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

2016-12-07 Thread Matthias welp
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 per char
formatted compared to your example. And as an extra you can use
hex strings (f"{0x30:c}" == "0") and any other integer literal you might want.

I don't see the added value of making character escapes in a non-default
way only (chars escaped + 1) bytes shorter, with the added maintenance
and development cost.

I think that you can do a lot with f-strings, and using the built-in formatting
options you can already get the behaviour you want in Python 3.6, months
earlier than the next opportunity (Python 3.7).

Check out the formatting options for integers and other built-in types here:
https://docs.python.org/3.6/library/string.html#format-specification-mini-language

I hope this helps solve your apparent usability problem.


-Matthias

On 8 December 2016 at 03:07, Mikhail V  wrote:
> 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 column,
>> but they're not organized/grouped decimally. Readability counts, and
>> introducing a competing syntax will make it harder for others to read.
>
> There were links to such table in previos discussion. Googling
> "unicode table decimal" and
> first link will it be.
> I think most online tables include decimals as well, usually as tuples
> of 8-bit decimals.
> Also earlier the decimal code was the first column in most tables, but
> it somehow settled in
> peoples' minds that hex reference should be preferred, for no solid reason 
> IMO.
> One reason I think due to HTML standards which started to use it in html files
> long ago and had much influence later, but one should understand,
> that is just for brevity in most cases. Other reason is, file viewers
> show hex by
> default, but that is just misfortune, nothin besides brevity and 4-bit
> word alignment
> gives the hex notation unfortunatly, at least in its current typeface.
> This was discussed actually in that thread.
> Many people also think they are cool hackers if they make everything in hex :)
> In some cases it is worth it, but not this case IMO. Mainly for
> bitwise stuff, but
> then one should look into binary/trinary/quaternary representation
> depending on nature
> of operations and hardware.
>
> Yes there is unicode table pagination correspondence in hex reference,
> but that hardly plays
> any positive role for real applications, most of the time I need to
> look in my code
> and also perform number operations on *specific* ranges and codes, but not
> on whole pages of the table. This could only play role if I do
> low-level filtering of large files
> and want to filter out data after character's page, but that is the
> only positive thing
> I can think of, and I don't think it is directly for Python.
>
> Imagine some cryptography exercise - you take 27 units, you just give
> them numbers (0..26)
> and you do calculations, yes you can view results as hex numbers, but
> I don't do it and most people
> don't and should not, since why? It is ugly and not readable.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


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

2016-11-14 Thread Matthias welp
>> For a mutable class, A = A + something is fundamentally different from
>> A += something.
>>
>> Paul

> Ok I am calmed down already.
> But how do you jump to lists already? I started an example with integers.
> I just want to increment an integer and I don't want to see any += in my code,
> it strains me. And that is exact reason I hate C syntax.
> Then Todd started about Numpy arrays. Ok, I just commented what I find for
> clearer syntax with array increment.
> And now lists, mutable classes... I don't use classes in my programs.
> I could propose something but how, if we mix everything in one big pile?
> Then my proposal is to make typed variables first, so I could
> at least consider use cases.

> Mikhail

Mikhail, what Paul probably means here is that python 'operators' are actually
'syntactic sugar' for functions (it is not recommended to call
these functions directly, but it is possible):

e.g. if you use 'a = a + 1', python under the hood interprets it as
'a = a.__add__(1)', but if you use 'a += 1' it uses 'a.__iadd__(1)'.
All python operators are implementable under functions, which is
part of the spec. For integers or strings, that may not be as visible to the
end user, but if you want to change the behaviour of operators,
please first look at the docs [1] and try to understand them, and
understand why they exists (inconclusive examples: [2).

I hope that this clears up the misconceptions you may have about how python
operators work.

-Matthias

[1]: https://docs.python.org/3/reference/datamodel.html#emulating-numeric-types
[2]: e.g. to make your library more efficient (like the operators in
numpy for more efficient array operations), or adding operator
functionality for numerical classes (like the decimal.Decimal class).
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/