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 surprised that multipr

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 connection iterable? It's the first > time I

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 -- it seems > >> like an obvious oversight. > > > > Wha

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. > > Actually recv() can raise an OSError corres

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 suppo

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 obvious about making a connection iterabl

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 view them as comparable

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 comparable to socket conne

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 line-oriented protocol. If yo

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 not iterable when using a line-oriented >

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] 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 non-d

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 mailing list Python-

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.

[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

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 Po

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 could ask the setupto

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 it

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 someli

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] 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 f

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: > . Aye, I linked

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 rather >> complex "

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 exception into operations that

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 shou

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 the > way that "window