Re: [Python-Dev] The socket HOWTO
On Sun, May 22, 2011 at 11:22 PM, Nick Coghlan wrote: > On Sun, May 22, 2011 at 3:38 AM, Georg Brandl wrote: > > On 05/21/11 18:01, Senthil Kumaran wrote: > >> So a rewrite with good pointers would be more appropriate. > > > > Even then, it's better off in the Wiki until the rewrite is complete. > > Perhaps replacing it with a placeholder page that refers to the Wiki > would be appropriate? A simple summary saying that the HOWTO had not > aged well, and hence had been removed from the official documentation > until it had been updated on the Wiki would allow people looking for > it to better understand the situation, and also how to help improve > it. > +1 on removal. +0.8 on the pointer with a disclaimer (please also add the disclaimer at the top of the socket howto as well). there's a lot of editorial misinformation in that page even if some parts of it are useful for the socket unaware... -gps ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.2): Fix ProcessTestCasePOSIXPurePython to test the module from import when
On Sun, May 29, 2011 at 2:13 AM, gregory.p.smith wrote: > Ironically: I don't think any platform should ever actually _use_ the > pure Python subprocess code on POSIX platforms anymore. This at least > tests it properly in this stable branch. The pure python code for > this is likely to be removed in 3.3. Don't do that - keeping the pure Python equivalents around can help reduce the level of effort for other implementations (especially PyPy). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.2): Fix ProcessTestCasePOSIXPurePython to test the module from import when
On Sun, May 29, 2011 at 11:08 PM, Nick Coghlan wrote: > On Sun, May 29, 2011 at 2:13 AM, gregory.p.smith > wrote: >> Ironically: I don't think any platform should ever actually _use_ the >> pure Python subprocess code on POSIX platforms anymore. This at least >> tests it properly in this stable branch. The pure python code for >> this is likely to be removed in 3.3. > > Don't do that - keeping the pure Python equivalents around can help > reduce the level of effort for other implementations (especially > PyPy). Never mind, you addressed that it in a later checkin. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The socket HOWTO
> I would like to suggest that we remove the socket HOWTO (currently at
> http://docs.python.org/dev/howto/sockets.html)
-1. I think there should be a Python-oriented introduction to sockets.
You may have complaints about the specific wording of the text, but
please understand that these are probably irrelevant to most
first-time readers of this text. My observation is that people actually
don't read the text that much, but instead try to imitate the examples.
So if the examples are good (and I think they are, mostly), it's of
minor relevance whether the text makes all sense the first time.
> - people who know sockets won't learn anything from it
True. People who know sockets just need to read the module
documentation. It is a beauty of the Python library design that it
exposes the API mostly as-is, so if you know Berkeley sockets,
you will be immediately familiar with Python sockets (unlike,
say, Java or .NET, where they decided to regroup the API into
classes).
> - but people who don't know sockets will probably find it clear as mud
See above - it doesn't really matter.
> (for example, what's an "INET" or "STREAM" socket?
You are probably referring to the sentence "I’m only going to talk about
INET sockets, but they account for at least 99% of the sockets in use.
And I’ll only talk about STREAM sockets" here. It's not important
to first-time readers to actually understand that, and the wording
explicitly tells them that they don't need to understand. It says
"there is more stuff, and you won't need it, and the stuff you need
is called INET and STREAM".
It's easy to fix, though, and I fixed it in f70e26452621 (explaining
that this is all about TCPv4).
> what's "select"?)
It's well explained in the section Non-blocking Sockets, isn't it?
> I have other issues, such as the style/tone it's written in. I'm sure
> the author had fun writing it but it doesn't fit well with the rest of
> the documentation. Also, the author gives a lot of "advice" without
> explaining or justifying it
It's a HOWTO - of course it has advise without justification. It's
not a reference documentation which only tells you what it does, but
not what the best way of putting it together is.
> ("if somewhere in those input lists of
> sockets is one which has died a nasty death, the select will fail" ->
> is that really true?
I think it is:
py> import select
py> select.select([100],[],[],0)
Traceback (most recent call last):
File "", line 1, in
select.error: (9, 'Bad file descriptor')
Of course, rather than "has died a nasty death", it could also say
"has been closed".
> what is a "nasty death" and how is that supposed to
> happen? couldn't the author have put a 3-line example to demonstrate
> this supposed drawback and how it manifests?).
It may well be that the author didn't fully understand the problem
when writing the text, so I wouldn't mind removing this specific
paragraph.
> And, finally, many statements seem arbitrary ("There’s no question that
> the fastest sockets code uses non-blocking sockets and select to
> multiplex them") or plain wrong ("threading support in Unixes varies
> both in API and quality. So the normal Unix solution is to fork a
> subprocess to deal with each connection").
I'd evaluate these two statements exactly vice versa. The first one
(non-blocking sockets are faster) is plain wrong, and the second one
("threading support in Unix varies") is arbitrary, but factually
correct :-)
I'd drop the entire "Performance" section - there is much more
to be said about socket performance than a few paragraphs of text,
and for the target audience, performance is probably no concern.
> Oh and I think it's obsolete too, because the "class mysocket"
> concatenates the output of recv() with a str rather than a bytes
> object.
That's easy to fix, too - c65e1a422bc3
> Not to mention that features of the "class mysocket" can be had
> using a buffered socket.makefile() instead of writing custom code.
I find it actually appropriate in the context. It illustrates a
number of important points about sockets, namely that you cannot
rely on send() and recv() to match in block size. Ultimately, people
that use the socket API *really* need to understand TCP, so it's
good to explain to them that there are issues to consider right
in the first tutorial.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PhD ideas
Hi, I'm now currently finishing my MsC and am thinking about enrolling into the PhD program. I was wondering if any of you would like to suggest me some research topic that could benefit the scientific community, that might also result as a potential improvement for Python. I love everything that's web related (Django here) and software engineering but I don't yet have any idea for a research topic that would be relevant for a PhD so I'm completely open to suggestions. Please contact me directly. Best regards -- Tiago Boldt Sousa ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASE] 3.1.4 release candidate 1
On behalf of the Python development team, I'm happy as a swallow to announce a release candidate for the fourth bugfix release for the Python 3.1 series, Python 3.1.4. 3.1.4 will the last bug fix release in the 3.1 series before 3.1. After 3.1.4, 3.1 will be in security-only fix mode. The Python 3.1 version series focuses on the stabilization and optimization of the features and changes that Python 3.0 introduced. For example, the new I/O system has been rewritten in C for speed. File system APIs that use unicode strings now handle paths with undecodable bytes in them. Other features include an ordered dictionary implementation, a condensed syntax for nested with statements, and support for ttk Tile in Tkinter. For a more extensive list of changes in 3.1, see http://doc.python.org/3.1/whatsnew/3.1.html or Misc/NEWS in the Python distribution. This is a testing release. To download Python 3.1.4rc1 visit: http://www.python.org/download/releases/3.1.4/ A list of changes in 3.1.4 can be found here: http://hg.python.org/cpython/file/35419f276c60/Misc/NEWS The 3.1 documentation can be found at: http://docs.python.org/3.1 Bugs can always be reported to: http://bugs.python.org Enjoy! -- Benjamin Peterson Release Manager benjamin at python.org (on behalf of the entire python-dev team and 3.1.4's contributors) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASE] Python 2.7.2 release candidate 1
On behalf of the Python development team, I'm happy to announce the immediate availability of Python 2.7.2 release candidate 1. 2.7.2 is the second in bugfix release for the Python 2.7 series. 2.7 is the last major verison of the 2.x line and will be receiving bug fixes while new feature development focuses on 3.x. 2.7 includes many features that were first released in Python 3.1. The faster io module, the new nested with statement syntax, improved float repr, set literals, dictionary views, and the memoryview object have been backported from 3.1. Other features include an ordered dictionary implementation, unittests improvements, a new sysconfig module, auto-numbering of fields in the str/unicode format method, and support for ttk Tile in Tkinter. For a more extensive list of changes in 2.7, see http://doc.python.org/dev/whatsnew/2.7.html or Misc/NEWS in the Python distribution. To download Python 2.7.2rc1 visit: http://www.python.org/download/releases/2.7.1/ The 2.7.2 changelog is at: http://hg.python.org/cpython/file/439396b06416/Misc/NEWS 2.7 documentation can be found at: http://docs.python.org/2.7/ This is a preview release. Assuming no major problems, 2.7.2 will be released in two weeks. Please report any bugs you find to http://bugs.python.org/ Enjoy! -- Benjamin Peterson Release Manager benjamin at python.org (on behalf of the entire python-dev team and 2.7.2's contributors) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASE] Python 2.7.2 release candidate 1
On Sun, May 29, 2011 at 6:47 PM, Benjamin Peterson wrote: > 2.7.2 is the second in bugfix release for the Python 2.7 series. 2.7 is the > last > major verison of the 2.x line and will be receiving bug fixes while new > feature > development focuses on 3.x. > > 2.7 includes many features that were first released in Python 3.1. It might not be clear to a casual reader that the features were released in 2.7.0 and not 2.7.2. We don't, but many projects do release new features with bugfix version numbers - I'm looking at you, Django. -Jack ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASE] Python 2.7.2 release candidate 1
2011/5/29 Jack Diederich : > On Sun, May 29, 2011 at 6:47 PM, Benjamin Peterson > wrote: >> 2.7.2 is the second in bugfix release for the Python 2.7 series. 2.7 is the >> last >> major verison of the 2.x line and will be receiving bug fixes while new >> feature >> development focuses on 3.x. >> >> 2.7 includes many features that were first released in Python 3.1. > > It might not be clear to a casual reader that the features were > released in 2.7.0 and not 2.7.2. We don't, but many projects do > release new features with bugfix version numbers - I'm looking at you, > Django. Okay. I suppose I can say "The 2.7 series" next time. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASE] Python 2.7.2 release candidate 1
On 05/29/2011 06:11 PM, Jack Diederich wrote: > We don't, but many projects do > release new features with bugfix version numbers - I'm looking at you, > Django. Really? Do you have an example of a new Django feature that was released in a bugfix version number? Just curious, since that's certainly not the documented release policy. [1] Carl [1] https://docs.djangoproject.com/en/dev/internals/release-process/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASE] Python 2.7.2 release candidate 1
Benjamin Peterson writes:
> The 2.7.2 changelog is at:
>
> http://hg.python.org/cpython/file/439396b06416/Misc/NEWS
>
The news file mentions that issue 1195 ("Problems on Linux with Ctrl-D
and Ctrl-C during raw_input") is fixed. That's not true, see:
http://bugs.python.org/msg135671
Does one need special roundup rights to reopen issues?
Cheers,
- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
