[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

new way to do it but it may be much slower and use much memory, so you shouldn't use it unless you can ignore performance." Regards, -- Inada Naoki ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-idea

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

$ python3 -m pyperf timeit -s 'x=[]; T=(str, list)' -- 'isinstance(x, T)' . Mean +- std dev: 73.1 ns +- 1.0 ns ``` Typing module doesn't have speedup extension. I expect`isinstance([], Union[str, list])` will be much slower than `isinstance([], (str, list))`. Regards, -- In

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

o implement runtime behavior for `str | int`. Regards, -- Inada Naoki ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

f foo() -> int | str: ... pass ... >>> foo.__annotations__ {'return': 'int | str'} Please read PEP 563. Regards, -- Inada Naoki ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

thon.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/FCTXGDT2NNKRJQ6CDEPWUXHVG2AAQZZY/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Inada Naoki

Re: [Python-ideas] Implement POSIX ln via shutil.link and shutil.symlink

implement this idiom directly in stdlib. tempfile.mkstemp doesn't support symlink. So people need to use external command `ln -sf` for now. Regards, -- Inada Naoki ___ 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] DB-API support for sets?

SQLAlchemy) provides better API for building query. Regards, -- Inada Naoki ___ 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] singledispatch for methods

ease try Python 3.8a3! https://docs.python.org/3.8/library/functools.html#functools.singledispatchmethod https://www.python.org/downloads/release/python-380a3/ -- Inada Naoki ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/m

Re: [Python-ideas] Allow not in lambda expressions

> Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Inada Naoki ___ 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] dict.merge(d1, d2, ...) (Counter proposal for PEP 584)

t;. > That would eliminate some of the difficulties with an operator, such as > the difference between + which requires both operands to be a dict > but += which can take any mapping or (key,value) iterable. > > -- > Steven -- Inada Naoki _

Re: [Python-ideas] Why operators are useful

the container's type. That's what Kotlin and Scala does. (Although Scala used ++ instead of +). ref: https://discuss.python.org/t/pep-584-survey-of-other-languages-operator-overload/977 Regards, -- Inada Naoki ___ Python-ideas mailing list Python-ideas@

Re: [Python-ideas] dict literal allows duplicate keys

uot; is the one that is > in effect. This is what happens with the LaTeX command > \providecommand. > > FURTHER LINKS > [6] https://docs.python.org/3/reference/expressions.html#dictionary-displays > [7] https://cwe.mitre.org/data/definitions/561.html # CWE

Re: [Python-ideas] PEP: Dict addition and subtraction

"d1 | d2" and "d1 & d2" would just be > confusing and misleading to encounter in the wild. Hmm. The PEP proposed dict - dict, which is similar to set - set (difference). To me, {"a": 1, "b": 2} - {"b": 3} = {"a": 1} is conf

Re: [Python-ideas] PEP: Dict addition and subtraction

There was a thread for the topic. https://mail.python.org/pipermail/python-dev/2018-October/155435.html 2019年3月6日(水) 2:02 Anders Hovmöller : > > On a related note: **kwargs, should they support arbitrary strings as > keys? I depend on this behavior in production code and all python >

Re: [Python-ideas] dict.merge(d1, d2, ...) (Counter proposal for PEP 584)

On Tue, Mar 5, 2019 at 7:59 PM Steven D'Aprano wrote: > > On Tue, Mar 05, 2019 at 06:04:40PM +0900, INADA Naoki wrote: > [...] > > One obvious merit of d.merge(...) is it returns same type of d. > > `type(d1)(d1, d2)` looks ugly. > > > > But people just want dic

Re: [Python-ideas] PEP: Dict addition and subtraction

On Tue, Mar 5, 2019 at 7:26 PM Steven D'Aprano wrote: > > On Sat, Mar 02, 2019 at 01:47:37AM +0900, INADA Naoki wrote: > > > If the keys are not strings, it currently works in CPython, but it may > > > not work with other implementations, or future versions of CPython[2

Re: [Python-ideas] Dict joining using + and +=

s added to dict for consistency. FWIW, Scala uses `++` for join all containers. Kotlin uses `+` for join all containers. (ref https://discuss.python.org/t/pep-584-survey-of-other-languages-operator-overload/977) Regards, -- Inada Naoki ___ Python-ide

Re: [Python-ideas] dict.merge(d1, d2, ...) (Counter proposal for PEP 584)

> * Type of returned value is always same to d1.copy(). No issubclass, > no __iadd__. I'm sorry, I meant __radd__, not __iadd__. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of

Re: [Python-ideas] dict.merge(d1, d2, ...) (Counter proposal for PEP 584)

On Tue, Mar 5, 2019 at 5:50 PM Nathaniel Smith wrote: > > On Mon, Mar 4, 2019 at 11:41 PM INADA Naoki wrote: > > Then, I propose `dict.merge` method. It is outer-place version > > of `dict.update`, but accepts multiple dicts. (dict.update() > > can be updated to accept

Re: [Python-ideas] dict.merge(d1, d2, ...) (Counter proposal for PEP 584)

On Tue, Mar 5, 2019 at 5:23 PM Chris Angelico wrote: > > On Tue, Mar 5, 2019 at 6:40 PM INADA Naoki wrote: > > This is why function and methods are better: > > > > * Easy to search. > > > > ## Merits of dict.merge() over operator + > > >

[Python-ideas] dict.merge(d1, d2, ...) (Counter proposal for PEP 584)

)? sorted() is a function so it looks different from L.sort() But d.updated() is very similar to d.update() for human eyes. ## How about d1 - d2? If it is really useful, it can be implemented as method too. dict.discard(sequence_of_keys) Regards, -- I

Re: [Python-ideas] PEP: Dict addition and subtraction

On Tue, Mar 5, 2019 at 12:02 AM Stefan Behnel wrote: > > INADA Naoki schrieb am 04.03.19 um 11:15: > > Why statement is not enough? > > I'm not sure I understand why you're asking this, but a statement is "not > enough" because it's a statement and not an

Re: [Python-ideas] Dict joining using + and +=

hod to builtin should have a high bar. Adding new operator to builtin should have a higher bar. Adding new syntax should have a highest bar. -- INADA Naoki ___ 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] PEP: Dict addition and subtraction

On Mon, Mar 4, 2019 at 6:52 PM Stefan Behnel wrote: > > I think the main intentions is to close a gap in the language. > > [1,2,3] + [4,5,6] > > works for lists and tuples, > > {1,2,3} | {4,5,6} > > works for sets, but joining two dicts isn't simply > > {1:2, 3:4} + {5:6} > Operators

Re: [Python-ideas] PEP: Dict addition and subtraction

> Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ -- INADA Naoki ___ 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] PEP: Dict addition and subtraction

gs. I think non string keys are allowed for {**d1, **d2} by language. -- INADA Naoki ___ 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] Dict joining using + and +=

se | than +. I just mean difference between dict.update() and seq+seq is not smaller than difference between dict.update() and set|set. If | seems not fit to this operation, + seems not fit to this operation too. -- INADA Naoki ___ Python-idea

Re: [Python-ideas] Dict joining using + and +=

it seems hard to call it "sum". Regards, 2019年3月1日(金) 23:19 Ivan Levkivskyi : > On Fri, 1 Mar 2019 at 13:48, INADA Naoki wrote: > >> > >> > >> > Is that an invariant you expect to apply to other uses of the + >> > operator? >> >

Re: [Python-ideas] Dict joining using + and +=

t;a": 3} -- It seems bit curious compared with + of sequence, because [2]+[3] is not [5]. It looks like more Counter than container. * ValueError -- Hmm, it looks ugly to me. So I don't think "sum" is not fit to dict semantics. Regards, -- INADA Naoki ___

Re: [Python-ideas] Dict joining using + and +=

On Fri, Mar 1, 2019 at 10:10 PM Steven D'Aprano wrote: > > On Fri, Mar 01, 2019 at 08:59:45PM +0900, INADA Naoki wrote: > > I dislike adding more operator overload to builtin types. > > > > str is not commutative, but it satisfies a in (a+b), and b in (a+b

Re: [Python-ideas] Dict joining using + and +=

org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- INADA Naoki ___ 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] PEP 8 and long string literals

I think long URL in comment or docstring is good reason to ignore line length limit. But I'm not sure about general long string literals. -- INADA Naoki ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo

Re: [Python-ideas] Using sha512 instead of md5 on python.org/downloads

formula and download site. If it's different, Homebrew or download site is under attack. So I think it's worth enough to moving to stronger and more used hash. (And by this reason, I prefer sha256 to sha512 for now.) -- INADA Naoki ___ Python-ide

Re: [Python-ideas] Add "default" kwarg to list.pop()

item. Unnecessary destructive change is bad. It reduces code readability, and it may create hard bug. If this proposal is adding `list.get([index[, default]])` too, I still -0. I don't know how often it is useful. Regards, -- INADA Naoki ___ Python-ide

Re: [Python-ideas] Pre-conditions and post-conditions

typing-usage-of-annotations "With this in mind, uses for annotations incompatible with the aforementioned PEPs should be considered deprecated." -- INADA Naoki ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/list

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

None`. Since `?.` and `?[]` can't avoid AttributeError, IndexError and KeyError, I think it's confusing and not useful enough compared with it's ugliness. So my current position is +1 for `??` and `??=`, but -1 for others. Regards, -- INADA Naoki

Re: [Python-ideas] Where should grouping() live (was: grouping / dict of lists)

e slave trade was to the 16th. > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- INADA Naoki ___ 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] String and bytes bitwise operations

module only for it. If bytearray ^= bytes is supported, websocket frame masking may look like: frame ^= mask * ((len(frame)+3)//4) # mask is 4 bytes long On Sat, Jun 23, 2018 at 1:26 AM Terry Reedy wrote: > On 6/22/2018 7:08 AM, INADA Naoki wrote: > > Bitwise xor is used for "

Re: [Python-ideas] String and bytes bitwise operations

gt; strings raise TypeErrors. > > Thanks. > > Suggesting, > Ken > ​ Hilton​ > ; > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http

Re: [Python-ideas] staticmethod and classmethod should be callable

. classmethod and staticmethod is just a function which modify the flag. ​But I'm not sure. Calling in Python is too complicated ​to fully understand. ​Regards,​ -- INADA Naoki ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.o

Re: [Python-ideas] Was `os.errno` undocumented?

gt; > And maybe this will encourage linters to flag this risky usage, if they > > aren't already doing so. > How do linters find out what's an internal import, and what's correct > usage (like os.path)? It is `correct usage` only when it is in __all__. >>> &q

Re: [Python-ideas] Change magic strings to enums

ecially for IntEnum.convert() or IntFlag.convert() in socket module. Regards, -- INADA Naoki <songofaca...@gmail.com> ___ 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] Change magic strings to enums

being enum's own module level code. > enum class creation cost is much heavier than "import enum" cost. Especially, "import socket, ssl" is much slower than before... -- INADA Naoki <songofaca...@gmail.com> ___ 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] Move optional data out of pyc files

uot;return":"int"}. This change will require new pyc format, and descriptor for PyFunction.__doc__, PyFunction.__annotation__ and type.__doc__. Regards, -- INADA Naoki <songofaca...@gmail.com> ___ Python-ideas mailing list P

Re: [Python-ideas] PEP draft: Unifying function/method classes

On Tue, Apr 3, 2018 at 12:46 AM, Jeroen Demeyer <j.deme...@ugent.be> wrote: > On 2018-04-02 12:39, INADA Naoki wrote: >> >> Thanks for writing such hard PEP. >> >> At first glance, it new type hierarchy seems OK. >> But I can't understand rational for new fl

Re: [Python-ideas] PEP draft: Unifying function/method classes

Thanks for writing such hard PEP. At first glance, it new type hierarchy seems OK. But I can't understand rational for new flags. And it's very difficult to estimate runtime and maintenance cost of the PEP, without draft implementation. FASTCALL is introduced in recently version, and it make

Re: [Python-ideas] Complicate str methods

eparator split is useful. The current best > solution is, like before, to use regex, or install a package and hope for > the best. > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of

Re: [Python-ideas] Adding str.isascii() ?

Hm, it seems I was too hurry to implement it... > > There were discussions about this. See for example > https://bugs.python.org/issue18814. > > In short, there are two considerations that prevented adding this feature: > > 1. This function can have the constant computation complexity in CPython

Re: [Python-ideas] Adding str.isascii() ?

> > That's fine with me. Please also add it to bytes and bytearray objects. It's > okay if the implementation has to scan the string -- so do isdigit() etc. > > -- > --Guido van Rossum (python.org/~guido) Thanks for your pronouncement! I'll do it in this weekend. Regard

Re: [Python-ideas] Adding str.isascii() ?

red at Amtsgericht Duesseldorf: HRB 46611 >http://www.egenix.com/company/contact/ > http://www.malemburg.com/ > > ___ > Python-ideas mailing list > Python-ideas@python.org > https:

Re: [Python-ideas] Adding str.isascii() ?

No. See this mail. https://mail.python.org/pipermail/python-ideas/2018-January/048748.html Point is should we support invalid Unicode created by C API. And I assume no. 2018/01/26 午後11:58 "Antoine Pitrou" <solip...@pitrou.net>: On Fri, 26 Jan 2018 22:33:36 +0900 INADA

Re: [Python-ideas] Adding str.isascii() ?

> > Can you create a simple test-case that proves this? Sure. $ git diff diff --git a/Modules/_testcapimodule.c b/Modules/_testcapimodule.c index 2ad4322eca..475d5219e1 100644 --- a/Modules/_testcapimodule.c +++ b/Modules/_testcapimodule.c @@ -5307,6 +5307,12 @@ PyInit__testcapi(void)

Re: [Python-ideas] Adding str.isascii() ?

/unicodeobject.c#L10871-L10873 https://github.com/python/cpython/blob/e76daebc0c8afa3981a4c5a8b54537f756e805de/Objects/unicodeobject.c#L10998-L10999 There may be many others, but I'm not sure. On Fri, Jan 26, 2018 at 10:02 PM, M.-A. Lemburg <m...@egenix.com> wrote: > On 26.01.2018 12:17, IN

Re: [Python-ideas] Adding str.isascii() ?

> No, because you can pass in maxchar to PyUnicode_New() and > the implementation will take this as hint to the max code point > used in the string. There is no check done whether maxchar > is indeed the minimum upper bound to the code point ordinals. API doc says: """ maxchar should be the true

Re: [Python-ideas] Adding str.isascii() ?

> +1 > > Just a note: checking the header in CPython will only give a hint, > since strings created using higher order kinds can still be 100% > ASCII. > Oh, really? I think checking header is enough for all ready unicode. For example, this is _PyUnicode_EqualToASCIIString implementation: if

[Python-ideas] Adding str.isascii() ?

and s.isdigit():` I want to add it in Python 3.7 if there are no opposite opinions. Regrads, -- INADA Naoki <songofaca...@gmail.com> ___ 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] Should Python have user-defined constants?

I'm -1. I feel Python is complex language already. And I don't want make it more complicate. INADA Naoki <songofaca...@gmail.com> On Tue, Nov 21, 2017 at 3:33 PM, Saeed Baig <saeedbaig...@icloud.com> wrote: > Hey guys I am thinking of perhaps writing a PEP to introduce user-defi

Re: [Python-ideas] Add time.time_ns(): system clock with nanosecond resolution

I'm completely +1 to Victor. nanosecond integer timestamp is used these days. And no complex newtype or newmodule is not needed for supporting it. INADA Naoki <songofaca...@gmail.com> On Fri, Oct 13, 2017 at 11:12 PM, Victor Stinner <victor.stin...@gmail.com> wrote: > Hi, &

Re: [Python-ideas] LOAD_NAME/LOAD_GLOBAL should be use getattr()

is almost enough to me. Then, what is real world requirement about abstraction layer to LOAD_GLOBAL? Regards, INADA Naoki <songofaca...@gmail.com> On Wed, Sep 13, 2017 at 1:17 AM, Neil Schemenauer <nas-python-id...@arctrix.com> wrote: > This is my idea of making module

Re: [Python-ideas] PEP 562

Oh, I'm shame myself. Only when `from email import *` is used, __all__ submodules are imported. INADA Naoki <songofaca...@gmail.com> On Mon, Sep 11, 2017 at 12:17 PM, Guido van Rossum <gu...@python.org> wrote: > I don't think submodules are automatically imported, unless t

Re: [Python-ideas] PEP 562

It looks simple and easy to understand. To achieve lazy import without breaking backward compatibility, I want to add one more rule: When package defines both of __getattr__ and __all__, automatic import of submodules are disabled (sorry, I don't have pointer to specification about this

Re: [Python-ideas] factory for efficient creation of many dicts with the same keys

it useful? When working on large dataset, I think list or tuple (or namedtuple) are recommended for records. If it's useful enough, it's worth enough to added in dict. It can't be implemented as 3rd party because relying on many private in dict. Regards, INADA Naoki <songofaca...@gmail.com>

Re: [Python-ideas] Fwd: Consider allowing the use of abstractmethod without metaclasses

> > I wonder if it would make sense to go further and merge *both* of these > features into regular classes. > > Checking for @abstractmethod in type.__new__ surely can't be that expensive, > can it? > But it affects startup time. It iterate all of the namespace and tries `getattr(obj,

Re: [Python-ideas] Fwd: Consider allowing the use of abstractmethod without metaclasses

INADA Naoki <songofaca...@gmail.com> On Fri, Jul 21, 2017 at 2:59 AM, Ivan Levkivskyi <levkivs...@gmail.com> wrote: > On 20 July 2017 at 19:51, INADA Naoki <songofaca...@gmail.com> wrote: >> >> On Fri, Jul 21, 2017 at 12:12 AM, Ivan Levkivskyi <levkivs...@gm

Re: [Python-ideas] Fwd: Consider allowing the use of abstractmethod without metaclasses

On Fri, Jul 21, 2017 at 12:12 AM, Ivan Levkivskyi wrote: > To be honest, I am not very happy with addition of a new special class. > Imagine that the PEP 544 will be accepted (and I hope so). > Then we would have, abstract classes, abstract base classes, and protocols. > I

Re: [Python-ideas] Fwd: Consider allowing the use of abstractmethod without metaclasses

effect. Additionally, even if CPython provide C implementation of ABCMeta, other Python implementations won't. So Abstract Class (not ABC) may be nice on such implementations too. I'm +1 to implement abc module in C. And I think (a) can be nice first step, instead of implement all at once. Regards, INADA

[Python-ideas] Fwd: Consider allowing the use of abstractmethod without metaclasses

ctBar(abc.Abstract): @abc.abstractmethod def bar(self): ... Bests, INADA Naoki <songofaca...@gmail.com> ___ 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] socket module: plain stuples vs named tuples

> > Would there be any benefit in making a C implementation available from > Python? > > -CHB > Yes, at startup time point of view. Current Python namedtuple implementation uses `eval`. It means we can't cache bytecode in pyc files. For example, importing functools is not so fast and its

Re: [Python-ideas] socket module: plain stuples vs named tuples

Namedtuple in Python make startup time slow. So I'm very conservative to convert tuple to namedtuple in Python. INADA Naoki <songofaca...@gmail.com> On Tue, Jun 20, 2017 at 7:27 AM, Victor Stinner <victor.stin...@gmail.com> wrote: > Oh, about the cost of writing C code, we sta

Re: [Python-ideas] pathlib.Path.walk

On Mon, Apr 3, 2017 at 5:33 PM, Michel Desmoulin wrote: > Like os.walk, but from a Path instance. > > We have Path.iterdir, but it's not recursive. Which you use either > os.scandir, or os.walk. In any case, you end up doing: > > import os > import pathlib > > directory

Re: [Python-ideas] pathlib.Path.walk

Why not Path.glob? https://docs.python.org/3.6/library/pathlib.html#pathlib.Path.glob On Mon, Apr 3, 2017 at 5:33 PM, Michel Desmoulin wrote: > Like os.walk, but from a Path instance. > > We have Path.iterdir, but it's not recursive. Which you use either > os.scandir,

Re: [Python-ideas] PEP: Python Documentation Translations

On Wed, Mar 22, 2017 at 10:18 AM, Victor Stinner wrote: >> Contributor Agreement >> ' >> >> Contributions to translated documentation will be requested to sign the >> Python Contributor Agreement (CLA): >> >>

Re: [Python-ideas] Exploiting type-homogeneity in list.sort() (again!)

Good job. I'll read your work later. > relatively simple optimization. I would also add that Python dictionaries > already implement this optimization: they start out optimizing based on the > assumption that they'll only be seeing string keys, checking to make sure > that assumption holds as

Re: [Python-ideas] [docs] https://docs.python.org/fr/ ?

>> Does hosting on Read the Docs makes any of this easier/harder? > > RTD models translations as separate projects, so it should make it > easier: > http://docs.readthedocs.io/en/latest/localization.html#project-with-multiple-translations > > Most importantly, because they're separate projects,

Re: [Python-ideas] https://docs.python.org/fr/ ?

There are some updates about this topic. And I have something to discuss to get things forward. We (Japanese translation team) and Julien start sharing one Transifex project. Please see this dashboard. We have nice progress. https://www.transifex.com/python-doc/python-35/dashboard/ Julien want

Re: [Python-ideas] PEP 538 (C locale coercion) now depends on PEP 540 (UTF-8 mode)

I love it PEP 540 helps using UTF-8 on Python. PEP 538 helps using UTF-8 on C libraries within Python, too, (if system supports LC_CTYPE=UTF-8 or C.UTF-8.) It seems best solution we can do for now. ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] RFC: PEP 540 version 3 (Add a new UTF-8 mode)

>> >> My question is more when A and B encodings are not compatible. >> >> Ah yes, date, thank you for the example. Here is my example using >> LC_TIME locale to format a date and LC_CTYPE to decode a byte string: > > Time and messages seem to behave differently - everything I tested > (including

Re: [Python-ideas] PEP 540: Add a new UTF-8 mode

On Fri, Jan 13, 2017 at 12:12 AM, Victor Stinner <victor.stin...@gmail.com> wrote: > 2017-01-12 1:23 GMT+01:00 INADA Naoki <songofaca...@gmail.com>: >> I'm ±0 to surrogateescape by default. I feel +1 for stdout and -1 for stdin. > > The use case is to be able to wri

Re: [Python-ideas] RFC: PEP 540 version 3 (Add a new UTF-8 mode)

> Thanks Victor, I really like this version, and the next time I update > PEP 538 I'm going to replace the en_US.UTF-8 fallback in the current > proposal with a dependency on this PEP. > When using en_US.UTF-8 as fallback, pleas override only LC_CTYPE, instead of LC_ALL. As I described in other

Re: [Python-ideas] Things that won't change (proposed PEP)

> Built-in functions > > -- > > > > Python is an object-oriented language, but it is not *purely* > > object-oriented. Not everything needs to be `a method of some object > `_, > > and functions have

Re: [Python-ideas] PEP 540: Add a new UTF-8 mode

> My PEP 540 is different than Nick's PEP 538, even for the POSIX > locale. I propose to always use the surrogateescape error handler, > whereas Nick wants to keep the strict error handler for inputs and > outputs. > https://www.python.org/dev/peps/pep-0540/#encoding-and-error-handler > > The

Re: [Python-ideas] PEP 540: Add a new UTF-8 mode

> > > (I wonder if we can use LC_CTYPE=UTF-8...) > > Syntactically incorrect: that means the language UTF-8. > "LC_TYPE=.UTF-8" might work, but IIRC the language tag is required, > the region and encoding are optional. Thus ja_JP, ja.UTF-8 are OK, > but .UTF-8 is not. I'm sorry. I know it, but

Re: [Python-ideas] PEP 540: Add a new UTF-8 mode

> > That kind of thing makes me very nervous, and I think justifiably so. > And it's only *sufficient* to justify a change to Python's defaults if > Python checks for and accurately identifies when it's in a container. > In my company, we use network boot servers. To reduce boot image, the image

Re: [Python-ideas] PEP 540: Add a new UTF-8 mode

> > Of course. The question is not "should cb@noaa properly configure > docker?", it's "Can docker properly configure docker (soon enough)? > And if not, should we configure Python?" The third question depends > on whether fixing it for you breaks things for others. When talking about general

Re: [Python-ideas] PEP 540: Add a new UTF-8 mode

> > The problem is if people have locales set for non-UTF-8, which Chinese > people often do ("GB18030 isn't just a good idea, it's the law"). > Especially forcing stdout to something other than the locale is likely > to mess things up. Oh, I didn't know non-UTF-8 is used for LC_CTYPE in these

Re: [Python-ideas] PEP 540: Add a new UTF-8 mode

>> Always use UTF-8 >> >> >> Python already always use the UTF-8 encoding on Mac OS X, Android and >> Windows. >> Since UTF-8 became the defacto encoding, it makes sense to always use it on >> all >> platforms with any locale. > >Please don't! I use different locales and

[Python-ideas] Force UTF-8 option regardless locale

up bit faster, because it can skip setting locale in startup. Any thoughts? How should the option be set? -- INADA Naoki <songofaca...@gmail.com> ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listi

<    1   2