Re: [Python-Dev] Backporting ensurepip to 2.7, Which commands to install?
[Replying to a mail that was sent before I joined this list. Quoting, headers, etc. aren't exactly right.] Nick Coghlan wrote: >On 4 October 2014 10:51, Donald Stufft wrote: >> Whoops, I misred. >> >> So to be clear, you think: >> >> install -> pip, pip2, pip2.7 >> altinstall -> pip2.7 > > To spell out the assumption I didn't make clear when helping with the > backport PEP, the difference comes from PEP 394, which specifies the > following behaviour when installing Python itself: > > Python 2.7: python, python2, python2.7 > Python 3.4: python3, python3.4 > > That maps to ensurepip as: > > Python 2.7: pip, pip2, pip2.7 > Python 3.4: pip3, pip3.4 I just installed Python 3.4.2 on Windows and noticed that its Scripts directory has these files out-of-the-box: easy_install.exe easy_install-3.4.exe. pip.exe pip3.exe pip3.4.exe Based on Nick's explanation above, having pip.exe there looks like bug in the installer and could easily cause a conflict with other pip installations. I don't understand why easy_install is included there in the first place, but easy_install.exe can obviously cause a similar conflict. Cheers, .peke -- Agile Tester/Developer/Consultant :: http://eliga.fi Lead Developer of Robot Framework :: http://robotframework.org ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting ensurepip to 2.7, Which commands to install?
On Wed, Oct 22, 2014 at 6:15 AM, Pekka Klärck wrote: > [Replying to a mail that was sent before I joined this list. Quoting, > headers, etc. aren't exactly right.] > > Nick Coghlan wrote: >>On 4 October 2014 10:51, Donald Stufft wrote: >>> Whoops, I misred. >>> >>> So to be clear, you think: >>> >>> install -> pip, pip2, pip2.7 >>> altinstall -> pip2.7 >> >> To spell out the assumption I didn't make clear when helping with the >> backport PEP, the difference comes from PEP 394, which specifies the >> following behaviour when installing Python itself: >> >> Python 2.7: python, python2, python2.7 >> Python 3.4: python3, python3.4 >> >> That maps to ensurepip as: >> >> Python 2.7: pip, pip2, pip2.7 >> Python 3.4: pip3, pip3.4 > > I just installed Python 3.4.2 on Windows and noticed that its Scripts > directory has these files out-of-the-box: > > easy_install.exe > easy_install-3.4.exe. > pip.exe > pip3.exe > pip3.4.exe > > Based on Nick's explanation above, having pip.exe there looks like bug > in the installer and could easily cause a conflict with other pip > installations. I don't understand why easy_install is included there > in the first place, but easy_install.exe can obviously cause a similar > conflict. Nick's explanation is based on PEP 394, which explicitly does not apply to Windows. The Windows Python executables are called "python.exe" and "pythonw.exe"; no "3" has ever been part of the name and it's not surprising that there's a matching "pip.exe". The pip3.exe and pip3.4.exe being installed are actually the anomalies here, but I wouldn't call them a bug. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting ensurepip to 2.7, Which commands to install?
On 22 October 2014 21:10, Geoffrey Spear wrote: > On Wed, Oct 22, 2014 at 6:15 AM, Pekka Klärck wrote: >> I just installed Python 3.4.2 on Windows and noticed that its Scripts >> directory has these files out-of-the-box: >> >> easy_install.exe >> easy_install-3.4.exe. >> pip.exe >> pip3.exe >> pip3.4.exe >> >> Based on Nick's explanation above, having pip.exe there looks like bug >> in the installer and could easily cause a conflict with other pip >> installations. I don't understand why easy_install is included there >> in the first place, but easy_install.exe can obviously cause a similar >> conflict. > > Nick's explanation is based on PEP 394, which explicitly does not > apply to Windows. The Windows Python executables are called > "python.exe" and "pythonw.exe"; no "3" has ever been part of the name > and it's not surprising that there's a matching "pip.exe". The > pip3.exe and pip3.4.exe being installed are actually the anomalies > here, but I wouldn't call them a bug. Right, the design on Windows is a little different, as the Python 3 executable has always remained "python.exe" there. Originally we followed PEP 394 style naming on Windows as well, but then realised during the 3.4 beta cycle that doing so didn't actually make sense (see http://bugs.python.org/issue20568 and http://bugs.python.org/issue20139) Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How io.IOBase.readline() should behave when used on non-blocking obj and no data available?
Hello,
On Thu, 16 Oct 2014 13:34:06 +0200
Antoine Pitrou wrote:
> On Thu, 16 Oct 2014 03:54:32 +0300
> Paul Sokolovsky wrote:
> > Hello,
> >
> > io.RawIOBase.read() is well specified for behavior in case it
> > immediately gets a would-block condition: "If the object is in
> > non-blocking mode and no bytes are available, None is returned."
> > (https://docs.python.org/3/library/io.html#io.RawIOBase.read).
> >
> > However, nothing is said about such condition for
> > io.IOBase.readline(), which is mixin method in a base class,
> > default implementation of which thus would use io.RawIOBase.read().
> > Looking at 3.4.0 source, iobase.c: iobase_readline() has:
> >
> > b = _PyObject_CallMethodId(self, &PyId_read, "n",
> > nreadahead); [...]
> > if (!PyBytes_Check(b)) {
> > PyErr_Format(PyExc_IOError,
> > "read() should have returned a bytes
> > object, " "not '%.200s'", Py_TYPE(b)->tp_name);
> >
> > I.e. it's not even ready to receive legitimate return value of None
> > from read(). I didn't try to write a testcase though, so may be
> > missing something.
> >
> > So, how readline() should behave in this case, and can that be
> > specified in the Library Reference?
>
> Well, the problem is that it's not obvious how to implement such
> methods in a non-blocking context.
>
> Let's says some data is received but there isn't a complete line.
> Should readline() return just that data (an incomplete line)? That
> breaks the API's contract. Should readline() buffer the incomplete
> line and keep it for the next readline() call? But then the internal
> buffer becomes unbounded: perhaps there is no new line in the next
> 4GB of incoming data...
>
> And besides, raw I/O objects *shouldn't* have an internal buffer.
> That's the role of the buffered I/O layer.
Yes, sure, readline() is defined on io.IOBase which is underspecified
for buffered-ness, so should have behavior which can be implemented for
both buffered and unbuffered case.
You're right also in saying that readline on non-blocking stream can't
work always the same way as blocking version, and that it "breaks the
API's contract". But it should be possible to extend that contract
for non-blocking readline() in pretty natural way:
1) An invariant of readline() is that it doesn't modify stream data,
it just segments it. So, readline() + write() looped until EOF will
produce the same result as read(N) + write(). Non-blocking readline()
will still satisfy this.
2) Even with blocking readline(), it can return a string not ending
with end-of-line character(s). For blocking readline, this may happen
with just the last line of a stream, with non-blocking, it may happen
for any call. The point is that even with blocking readline(), the
caller should be ready to check that a line satisfies its "complete
line" criteria, for non-blocking case, it's just will be different set
of criteria and actions to satisfy them.
I guess, defining non-blocking readline() in such way is better then
let it be underspecified whether it's supported or not (and if yes,
then how), or prohibit it.
--
Best regards,
Paul mailto:[email protected]
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How io.IOBase.readline() should behave when used on non-blocking obj and no data available?
Hello, On Thu, 16 Oct 2014 07:50:02 -0700 Guido van Rossum wrote: [] > > > So, how readline() should behave in this case, and can that be > > > specified in the Library Reference? > > > > Well, the problem is that it's not obvious how to implement such > > methods in a non-blocking context. > > > > Let's says some data is received but there isn't a complete line. > > Should readline() return just that data (an incomplete line)? That > > breaks the API's contract. Should readline() buffer the incomplete > > line and keep it for the next readline() call? But then the > > internal buffer becomes unbounded: perhaps there is no new line in > > the next 4GB of incoming data... > > > > And besides, raw I/O objects *shouldn't* have an internal buffer. > > That's the role of the buffered I/O layer. > > > [] > (if any). If the underlying stream returns None, I think it makes > sense for readline() to return None too -- attempting to read more > will just turn into a busy-wait loop, and that's the opposite of what > should happen. > [] > > (Alternatively, we could raise BlockingIOError, which is that the OS > level read() raises if there's no data immediately available on a > non-blocking FD; but it seems that streams have already gotten a Yes, that's the choices I had in mind - either return None, or raise an exception. Thanks for confirming that None is a better choice here, that's what I implemented in MicroPython. Thanks for other points and commentary too. -- Best regards, Paul mailto:[email protected] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
