Re: [Python-ideas] Support WHATWG versions of legacy encodings

On 10 January 2018 at 13:56, Rob Speer wrote: > One other thing I've noticed that's related to the WHATWG encoding list: in > Python, the encoding name "windows-874" seems to be missing. The _encoding_ > is there, as "cp874", but "windows-874" doesn't work as an alias for it

Re: [Python-ideas] Support WHATWG versions of legacy encodings

One other thing I've noticed that's related to the WHATWG encoding list: in Python, the encoding name "windows-874" seems to be missing. The _encoding_ is there, as "cp874", but "windows-874" doesn't work as an alias for it the way that "windows-1252" works as an alias for "cp1252". That alias

Re: [Python-ideas] Support WHATWG versions of legacy encodings

On 10 January 2018 at 09:56, Rob Speer wrote: > Oh that's interesting. So it seems to be Python that's the exception here. > > Would we really be able to add entries to character mappings that haven't > changed since Python 2.0? Changing things that used to cause an

Re: [Python-ideas] Syntax to import modules before running command from the command line

On 10 January 2018 at 07:54, Barry Warsaw wrote: > Steve Barnes wrote: >> Currently invoking `python -c "some;separated;set of commands;"` will, >> if you need to use any library functions, require one or more import >> somelib; sections in the execution string. This results in

Re: [Python-ideas] pdb to support running modules

On 10 January 2018 at 05:18, Alexander Belopolsky wrote: > On Thu, Jan 4, 2018 at 8:15 PM, Guido van Rossum wrote: >> Sounds uncontroversial, this can just be done via bugs.python.org. >> > > .. and it has been proposed there over 7 years ago: >

Re: [Python-ideas] Support WHATWG versions of legacy encodings

Oh that's interesting. So it seems to be Python that's the exception here. Would we really be able to add entries to character mappings that haven't changed since Python 2.0? On Tue, 9 Jan 2018 at 16:53 Ivan Pozdeev via Python-ideas < python-ideas@python.org> wrote: > First of all, many thanks

Re: [Python-ideas] Syntax to import modules before running command from the command line

On 10.01.2018 0:54, Barry Warsaw wrote: Steve Barnes wrote: Currently invoking `python -c "some;separated;set of commands;"` will, if you need to use any library functions, require one or more import somelib; sections in the execution string. This results in rather complex "one liners". On the

Re: [Python-ideas] Syntax to import modules before running command from the command line

Steve Barnes wrote: > Currently invoking `python -c "some;separated;set of commands;"` will, > if you need to use any library functions, require one or more import > somelib; sections in the execution string. This results in rather > complex "one liners". > > On the other hand `python -m

Re: [Python-ideas] Support WHATWG versions of legacy encodings

First of all, many thanks for such a excellently writen letter. It was a real pleasure to read. On 10.01.2018 0:15, Rob Speer wrote: Hi! I joined this list because I'm interested in filling a gap in Python's standard library, relating to text encodings. There is an encoding with no name of

Re: [Python-ideas] Allow to compile debug extension against releasePython in Windows

> On 9 Jan 2018, at 20:35, Ivan Pozdeev wrote: > > On 09.01.2018 23:31, Barry Scott wrote: >> I not a user of distutils or setuptools but some googling seems to say that >> the build command has a --debug to do what you want. If that does not >> work it would seem like you

Re: [Python-ideas] Allow to compile debug extension against releasePython in Windows

I not a user of distutils or setuptools but some googling seems to say that the build command has a --debug to do what you want. If that does not work it would seem like you could ask the setuptools maintainers how to do the reason thing of a debug build. Barry > On 9 Jan 2018, at 18:46, Ivan

[Python-ideas] Support WHATWG versions of legacy encodings

Hi! I joined this list because I'm interested in filling a gap in Python's standard library, relating to text encodings. There is an encoding with no name of its own. It's supported by every current web browser and standardized by WHATWG. It's so prevalent that if you ask a Web browser to decode

Re: [Python-ideas] Allow to compile debug extension against releasePython in Windows

On 09.01.2018 23:31, Barry Scott wrote: I not a user of distutils or setuptools but some googling seems to say that the build command has a --debug to do what you want. If that does not work it would seem like you could ask the setuptools maintainers how to do the reason thing of a debug build.

Re: [Python-ideas] pdb to support running modules

On Thu, Jan 4, 2018 at 8:15 PM, Guido van Rossum wrote: > Sounds uncontroversial, this can just be done via bugs.python.org. > .. and it has been proposed there over 7 years ago: . ___ Python-ideas

Re: [Python-ideas] Allow to compile debug extension against releasePython in Windows

On 09.01.2018 21:35, Ivan Pozdeev via Python-ideas wrote: On 08.01.2018 0:11, Steve Dower wrote: It’s not a good idea. You end up with two different C runtimes in memory that cannot communicate, and many things will not work properly. If you compile your debug build extension with the

Re: [Python-ideas] Allow to compile debug extension against releasePython in Windows

On 08.01.2018 0:11, Steve Dower wrote: It’s not a good idea. You end up with two different C runtimes in memory that cannot communicate, and many things will not work properly. If you compile your debug build extension with the non-debug CRT (/MD rather than /MDd) you will lose asserts, but

Re: [Python-ideas] make Connections iterable

On Tue, 9 Jan 2018 08:39:06 -0800 Nathaniel Smith wrote: > On Jan 9, 2018 04:12, "Random832" wrote: > > On Tue, Jan 9, 2018, at 05:46, Nick Coghlan wrote: > > If you view them as comparable to subprocess pipes, then it can be > > surprising that they're

Re: [Python-ideas] make Connections iterable

On 01/09/2018 08:27 AM, Chris Angelico wrote: On Tue, Jan 9, 2018 at 11:12 PM, Random832 wrote: On Tue, Jan 9, 2018, at 05:46, Nick Coghlan wrote: If you view them as comparable to subprocess pipes, then it can be surprising that they're not iterable when using a

Re: [Python-ideas] make Connections iterable

On Jan 9, 2018 04:12, "Random832" wrote: On Tue, Jan 9, 2018, at 05:46, Nick Coghlan wrote: > If you view them as comparable to subprocess pipes, then it can be > surprising that they're not iterable when using a line-oriented > protocol. > > If you instead view them as

Re: [Python-ideas] make Connections iterable

On Tue, Jan 9, 2018 at 11:12 PM, Random832 wrote: > On Tue, Jan 9, 2018, at 05:46, Nick Coghlan wrote: >> If you view them as comparable to subprocess pipes, then it can be >> surprising that they're not iterable when using a line-oriented >> protocol. >> >> If you instead

Re: [Python-ideas] make Connections iterable

09.01.18 12:46, Nick Coghlan пише: On 9 January 2018 at 20:07, Antoine Pitrou wrote: On Mon, 8 Jan 2018 21:22:56 -0800 Nathaniel Smith wrote: I'm surprised that multiprocessing.Connection isn't iterable -- it seems like an obvious oversight. What is

Re: [Python-ideas] make Connections iterable

On Tue, Jan 9, 2018, at 05:46, Nick Coghlan wrote: > If you view them as comparable to subprocess pipes, then it can be > surprising that they're not iterable when using a line-oriented > protocol. > > If you instead view them as comparable to socket connections, then the > lack of iteration

Re: [Python-ideas] make Connections iterable

On Tue, Jan 9, 2018 at 2:07 AM, Antoine Pitrou wrote: > On Mon, 8 Jan 2018 21:22:56 -0800 > Nathaniel Smith wrote: >> >> The only documented error from multiprocessing.Connection.recv is EOFError, >> which is basically equivalent to a StopIteration. > >

Re: [Python-ideas] make Connections iterable

On Tue, 9 Jan 2018 20:46:35 +1000 Nick Coghlan wrote: > On 9 January 2018 at 20:07, Antoine Pitrou wrote: > > On Mon, 8 Jan 2018 21:22:56 -0800 > > Nathaniel Smith wrote: > >> I'm surprised that multiprocessing.Connection isn't iterable

Re: [Python-ideas] make Connections iterable

On 9 January 2018 at 20:07, Antoine Pitrou wrote: > On Mon, 8 Jan 2018 21:22:56 -0800 > Nathaniel Smith wrote: >> I'm surprised that multiprocessing.Connection isn't iterable -- it seems >> like an obvious oversight. > > What is obvious about making a

Re: [Python-ideas] make Connections iterable

On Mon, 8 Jan 2018 21:22:56 -0800 Nathaniel Smith wrote: > > The only documented error from multiprocessing.Connection.recv is EOFError, > which is basically equivalent to a StopIteration. Actually recv() can raise an OSError corresponding to any system-level error. > I'm