Re: [Python-Dev] The socket HOWTO
On Mon, 06 Jun 2011 00:22:11 +0200 "Martin v. Löwis" wrote: > >>> I'm not sure why the examples are good (for example, modern client > >>> code should probably use create_connection() with a host name, not > >>> connect()). > >> > >> I disagree. create_connection is an advanced function - you shouldn't > >> be using it unless you know what it is doing. > > > > Can you explain? I would certainly use it myself, and I don't > > understand how it's "advanced". It's simply higher-level. > > It uses getaddrinfo, which might return multiple addresses, which > are then tried in sequence. So even though it's called > "create_connection", it may actually attempt to create multiple > connections. As a consequence, it may wait some time for one connection > to complete, and then succeed on a different address. > > These phenomena can only be understood when you know what it is > actually doing. So what? You can say the exact same thing about every API under the sun. Yet the sockets HOWTO *doesn't* explain what the socket APIs are actually doing. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: always clear parser error
On 06/06/11 05:13, benjamin.peterson wrote: > http://hg.python.org/cpython/rev/9faa9270457e > changeset: 70654:9faa9270457e > user:Benjamin Peterson > date:Sun Jun 05 22:14:05 2011 -0500 > summary: > always clear parser error > > files: > Modules/parsermodule.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) This looks like a fixup of rev 3ffd8dea77bf; it would be nice to say so in the commit message: the current message is not obvious at all. Georg ___ Python-Dev mailing list [email protected] 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
[email protected] writes: > However, does that really have anything to do with improving the socket > howto? Thank you! > The Python documentation can include a clear explanation of what > functionality the socket module provides - without forcing you to read > Stevens _or_ use Twisted, but it can still refer you to both, since it > is very likely that you'll need at least one of them in addition to the > socket module. +1 I suggest s/very likely/likely/, though. ___ Python-Dev mailing list [email protected] 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
Antoine Pitrou writes: > Did you run a user survey? Martin undoubtedly has a lot of experience with users, and it's quite reasonable for him to express his opinions based on that informal sample, yes. The issue here is the difference between existential and universal quantifiers. Martin's arguments are not inconsistent. They simply acknowledge the existence of subsamples of users of the same document with different needs and/or approaches to reading the document. He does not and has never claimed that all of his arguments apply to all of the potential readers. You might question whether the same document should serve both the "cargo cult the examples" group and the "read the fine print" group. That's a valid question, but here my feeling is that the answer is "yes". I very often "cargo cult" my first program, then go back to the fine print and experiment by gradually changing that program to test my understanding of the detailed explanations. It is often easiest to use the same document for both purposes because I already know where it is and the quality of the writing. ___ Python-Dev mailing list [email protected] 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
Le lundi 06 juin 2011 à 17:01 +0900, Stephen J. Turnbull a écrit : > You might question whether the same document should serve both the > "cargo cult the examples" group and the "read the fine print" group. > That's a valid question, but here my feeling is that the answer is > "yes". So did you read the discussion before posting? The sockets HOWTO *doesn't* serve both groups. Actually, I would argue that it serves neither of them. ___ Python-Dev mailing list [email protected] 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
> > Did you run a user survey? > > Martin undoubtedly has a lot of experience with users, and it's quite > reasonable for him to express his opinions based on that informal > sample, yes. In particular, this is collected experience from interaction with students learning Python, or other languages. When they try to solve a problem, they don't read specification-style documentation. Instead they look for examples that they can imitate. [I notice that you (Stephen) also confirmed this from your own experience] > The issue here is the difference between existential and universal > quantifiers. Martin's arguments are not inconsistent. They simply > acknowledge the existence of subsamples of users of the same document > with different needs and/or approaches to reading the document. He > does not and has never claimed that all of his arguments apply to all > of the potential readers. Exactly so. I'd like to settle this discussion based on the anecdotal report of several users on this list that they considered the tutorial useful. > You might question whether the same document should serve both the > "cargo cult the examples" group and the "read the fine print" group. > That's a valid question, but here my feeling is that the answer is > "yes". I very often "cargo cult" my first program, then go back to > the fine print and experiment by gradually changing that program to > test my understanding of the detailed explanations. It is often > easiest to use the same document for both purposes because I already > know where it is and the quality of the writing. In that spirit, I'd be in favor of removing outright errors from the document, and overly subjective and argumentative passages. Other than that, I still think its fine as it stands. Regards, Martin ___ Python-Dev mailing list [email protected] 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
Am 06.06.2011 10:11, schrieb Antoine Pitrou: > Le lundi 06 juin 2011 à 17:01 +0900, Stephen J. Turnbull a écrit : >> You might question whether the same document should serve both the >> "cargo cult the examples" group and the "read the fine print" group. >> That's a valid question, but here my feeling is that the answer is >> "yes". > > So did you read the discussion before posting? The sockets HOWTO > *doesn't* serve both groups. > Actually, I would argue that it serves neither of them. How can you make such claims when several people have indicated that the howto *actually* helped them? Please let this rest. Regards, Martin ___ Python-Dev mailing list [email protected] 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
On Mon, 06 Jun 2011 10:33:14 +0200 "Martin v. Löwis" wrote: > Am 06.06.2011 10:11, schrieb Antoine Pitrou: > > Le lundi 06 juin 2011 à 17:01 +0900, Stephen J. Turnbull a écrit : > >> You might question whether the same document should serve both the > >> "cargo cult the examples" group and the "read the fine print" group. > >> That's a valid question, but here my feeling is that the answer is > >> "yes". > > > > So did you read the discussion before posting? The sockets HOWTO > > *doesn't* serve both groups. > > Actually, I would argue that it serves neither of them. > > How can you make such claims when several people have indicated that > the howto *actually* helped them? The point here is that the examples in that document are very poor (the only substantial example actually duplicates existing functionality - in a sub-optimal manner - without even mentioning the existence of said functionality), and the technical explanations are nearly non-existent. So I'll happy stand by my claims. The Python documentation isn't meant to host any potentially helpful document, however flawed. We have the Internet for that. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Buildbots and regrtest timeout
Hi,
Stephan Krah asked me to change how the default timeout is defined for regrtest
(issue #12250):
"The implicit timeout in regrtest.py makes it harder to write automated
test scripts for 3rd party modules. First, you have to remember to
set --timeout=0 for long running tests. Then, you have to remember
not to use the --timeout option when compiling --without-threads.
I'd much prefer that there's no timeout unless explicitly specified.
For the buildbots, I think this could be done in the Makefile."
First I replaced the hardcoded constant in regrtest.py by a command line
argument (--timeout=3600) in the TESTOPTS variable of the Makefile, so if you
call regrtest directly (without make), there is no more default timeout.
But today I saw a a buildbot timeout without any traceback: a possible hang in
test_io on "x86 FreeBSD 7.2 3.x" buildbot, "command timed out: 3900 seconds
without output". I realized that some buildbots (all buildbots?) override the
TESTOPTS variable ("make buildbottest TESTOPTS= TESTPYTHONOPTS=" for "x86
FreeBSD 7.2 3.x").
I moved the timeout option from TESTOPTS to a new variable: TESTTIMEOUT, with
a default value of 1 hour (3600 seconds). The timeout is now only used for
"make buildbottest". Use TESTTIMEOUT=0 to disable completly regrtest timeout.
The timeout argument if ignored (with a warning) if
faulthandler.dump_tracebacks_later() function is missing (e.g. if Python is
compiled without threads).
Please, don't disable the TESTTIMEOUT option for your buildbot. You may want
to use a shorter or longer timeout, it just have to be smaller than the
buildbot timeout (3900 seconds by default, 1 hour 6 minutes, just a little bit
more than regrtest timeout: 1 hour). If you want a timeout longer than 1 hour,
you can to change TESTTIMEOUT and the buildbot timeout (I don't know how to
configure the buildbot timeout).
I didn't touch test, testall, testuniversal, quicktest make rules, which don't
use the regrtest timeout anymore. I would prefer to use the same timeout
options for all test rules in TESTOPTS, but it doesn't work because some
buildbots do override TESTOPTS variable.
Victor
___
Python-Dev mailing list
[email protected]
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
Antoine Pitrou wrote: On Mon, 06 Jun 2011 10:33:14 +0200 "Martin v. Löwis" wrote: [...] How can you make such claims when several people have indicated that the howto *actually* helped them? The point here is that the examples in that document are very poor (the only substantial example actually duplicates existing functionality - in a sub-optimal manner - without even mentioning the existence of said functionality), and the technical explanations are nearly non-existent. So I'll happy stand by my claims. You know, for the amount of discussion about whether or not the doc is worth keeping, we probably could have fixed all the problems with it :) I believe that "status quo wins" is worth applying here. In the absence of evidence that the HOWTO is actively harmful, we should keep it. I'm of two minds whether it should go into the wiki. I would hate for the wiki to become the place where bad docs go to die, but on the other hand putting it in the wiki may encourage lightweight incremental fixes. I think the Socket HOWTO is important enough to fix, not throw out. I also dislike link-rot, and throwing it out causes link-rot. I'd rather see a bunch of concrete bug reports for the HOWTO than just a dismissive "throw it out and start again". The Python documentation isn't meant to host any potentially helpful document, however flawed. We have the Internet for that. I think it is unfair to dismiss the document as "potentially" helpful when a number of people have said that it *actually* did help them. -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbots and regrtest timeout
On 6 June 2011 11:29, Victor Stinner wrote:
> Stephan Krah asked me to change how the default timeout is defined for
> regrtest
> (issue #12250):
>
> "The implicit timeout in regrtest.py makes it harder to write automated
> test scripts for 3rd party modules. First, you have to remember to
> set --timeout=0 for long running tests. Then, you have to remember
> not to use the --timeout option when compiling --without-threads.
>
> I'd much prefer that there's no timeout unless explicitly specified.
> For the buildbots, I think this could be done in the Makefile."
>
> First I replaced the hardcoded constant in regrtest.py by a command line
> argument (--timeout=3600) in the TESTOPTS variable of the Makefile, so if you
> call regrtest directly (without make), there is no more default timeout.
>
> But today I saw a a buildbot timeout without any traceback: a possible hang in
> test_io on "x86 FreeBSD 7.2 3.x" buildbot, "command timed out: 3900 seconds
> without output". I realized that some buildbots (all buildbots?) override the
> TESTOPTS variable ("make buildbottest TESTOPTS= TESTPYTHONOPTS=" for "x86
> FreeBSD 7.2 3.x").
>
> I moved the timeout option from TESTOPTS to a new variable: TESTTIMEOUT, with
> a default value of 1 hour (3600 seconds). The timeout is now only used for
> "make buildbottest". Use TESTTIMEOUT=0 to disable completly regrtest timeout.
> The timeout argument if ignored (with a warning) if
> faulthandler.dump_tracebacks_later() function is missing (e.g. if Python is
> compiled without threads).
>
> Please, don't disable the TESTTIMEOUT option for your buildbot. You may want
> to use a shorter or longer timeout, it just have to be smaller than the
> buildbot timeout (3900 seconds by default, 1 hour 6 minutes, just a little bit
> more than regrtest timeout: 1 hour). If you want a timeout longer than 1 hour,
> you can to change TESTTIMEOUT and the buildbot timeout (I don't know how to
> configure the buildbot timeout).
>
> I didn't touch test, testall, testuniversal, quicktest make rules, which don't
> use the regrtest timeout anymore. I would prefer to use the same timeout
> options for all test rules in TESTOPTS, but it doesn't work because some
> buildbots do override TESTOPTS variable.
How does this impact Windows buildbots? As they don't use the
makefile, did you add an override to the Windows scripts as well, or
will WIndows now use the default of no timeout?
Paul.
___
Python-Dev mailing list
[email protected]
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
Antoine Pitrou writes: > So did you read the discussion before posting? Yes. It's rude to assume that those who disagree with you are irresponsible and uninformed. Would you please stop it? > The sockets HOWTO *doesn't* serve both groups. > Actually, I would argue that it serves neither of them. I know that is your opinion, because I've read your posts. I disagree. The document is imperfect, but for me it served a certain purpose. Therefore I stand with the camp that says improving the document is the way to go. ___ Python-Dev mailing list [email protected] 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
Le lundi 06 juin 2011 à 22:59 +0900, Stephen J. Turnbull a écrit : > Antoine Pitrou writes: > > > So did you read the discussion before posting? > > Yes. It's rude to assume that those who disagree with you are > irresponsible and uninformed. Would you please stop it? > > > The sockets HOWTO *doesn't* serve both groups. > > Actually, I would argue that it serves neither of them. > > I know that is your opinion, because I've read your posts. I > disagree. The document is imperfect, but for me it served a certain > purpose. Therefore I stand with the camp that says improving the > document is the way to go. Don't hesitate to contribute. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging landed in stdlib
Hi, My GSoC student made me realize that it could be quite difficult to work with the packaging module codebase when you’re familiar with the distutils code. I wrote a blog post about file-level changes from distutils to packaging, to help people find their way: https://wokslog.wordpress.com/2011/06/04/distutils-diff/ Regards ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Help requested for Python ISO Standard
To whom it may concern: I am working on an ISO Annex of Vulnerabilities for the Python language and am asking for help getting a list of language features that exhibit: unspecified behavior, undefined behavior, or implementation defined behavior. I am also searching for a list of deprecated features. Guido (copied) had suggested I contact you folks for help as we are coming up on an ISO deadline and I have not been successful finding this information. Thanks very much in advance for your help! Regards, Kevin Coyne Cell: 703.901.6774 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbots and regrtest timeout
Victor Stinner writes:
> But today I saw a a buildbot timeout without any traceback: a possible hang
> in
> test_io on "x86 FreeBSD 7.2 3.x" buildbot, "command timed out: 3900 seconds
> without output". I realized that some buildbots (all buildbots?) override the
> TESTOPTS variable ("make buildbottest TESTOPTS= TESTPYTHONOPTS=" for "x86
> FreeBSD 7.2 3.x").
(...)
> Please, don't disable the TESTTIMEOUT option for your buildbot. You may want
> to use a shorter or longer timeout, (...)
Just a note, given the phrasing above. None of this is anything that
I for example, as a buildbot operator, am actively controlling. That
command, including the environment variable overrides, is exactly as
provided by the master for a given test run. So I'd think you could
adjust it if needed through changes in the master build configuration
and probably without having to add an environment variable or
Per Paul's follow-up on Windows, buildbot under Windows seems to
impose a 1200s idle timeout (just for no output), but I'm not positive
how it's calculated. The test process itself has never, I'm pretty
sure, specified a timeout to regrtest (via the test.bat, rt.bat,
regrtest.py path). (Oh, I guess the --timeout option itself in
regrtest is fairly new)
So if there's a change in defaults for regrtest that will change
Windows behavior implicitly, and I believe at this point the buildbots
will be inconsistent, since you're only overriding the regrtest
default in a subset of buildbot types.
-- David
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FWD: gpg keys have problems
On Jun 05, 2011, at 08:20 AM, Aahz wrote: >> >From your python download page you need to update the public keys to not >> use the faulty MD5 digest algorithm. (see the link listed below) >> >> $ gpg --import pubkeys.txt >> gpg: key 6A45C816: public key "Anthony Baxter " >> imported >> gpg: WARNING: digest algorithm MD5 is deprecated >> gpg: please see http://www.gnupg.org/faq/weak-digest-algos.html for more >> information >> gpg: key ED9D77D5: public key "Barry A. Warsaw " imported >> gpg: Total number processed: 2 >> gpg: imported: 2 (RSA: 1) >> gpg: no ultimately trusted keys found This only looks like a problem with Anthony's key. He could update his key, but OTOH probably has little incentive to just for Python release management. Anthony was release manager for 2.5, but Martin took that over, and also, Python 2.5 is very near EOL even for security releases. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Help requested for Python ISO Standard
kevin> I am working on an ISO Annex of Vulnerabilities for the Python kevin> language and am asking for help getting a list of language kevin> features that exhibit: kevin> unspecified behavior, undefined behavior, or implementation kevin> defined behavior. I am also searching for a list of deprecated kevin> features. One place to search: http://svn.python.org/projects/python/branches/py3k/Lib/test/crashers/ -- Skip Montanaro - [email protected] - http://www.smontanaro.net/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] AIX 5.3 - Build of Python 2.7.1
Hi All, Python2.7.1 build on AIX 5.3 ML 12 is failing at the make step with the error indicated below de -I./Include -I /opt/freeware/include -I /opt/freeware/include/readline -I /opt/freeware/include/ncurses -DPy_BUILD_CORE -o Parser/tokenizer_pgen.o Parser/tokenizer_pgen.c gcc -pthread -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I /opt/freeware/include -I /opt/freeware/include/readline -I /opt/freeware/include/ncurses -DPy_BUILD_CORE -o Parser/printgrammar.o Parser/printgrammar.c gcc -pthread -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I /opt/freeware/include -I /opt/freeware/include/readline -I /opt/freeware/include/ncurses -DPy_BUILD_CORE -o Parser/pgenmain.o Parser/pgenmain.c gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/mysnprintf.o Python/pyctype.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/pgenmain.o -ldl -o Parser/pgen ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 559) in object Parser/grammar1.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 579) in object Parser/firstsets.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. collect2: ld returned 12 exit status make: 1254-004 The error code from the last command is 1. Is there anything I could try to get past this? Here is the configuration and make step that i utilized ./configure –enable-shared --disable-ipv6 --with-gcc=gcc CPPFLAGS="-I /opt/freeware/include -I /opt/freeware/include/readline -I /opt/freeware/include/ncurses" make Regards, Anurag ___ Python-Dev mailing list [email protected] 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
> Date: Mon, 6 Jun 2011 22:59:04 +0900 > From: [email protected] > To: [email protected] > CC: [email protected] > Subject: Re: [Python-Dev] The socket HOWTO > > I know that is your opinion, because I've read your posts. I > disagree. The document is imperfect, but for me it served a certain > purpose. Therefore I stand with the camp that says improving the > document is the way to go. +1. I've been reading the postings on this discussion intently, as I have had experience with the socket HOWTO when I was first learning about sockets. I agree with the view that Martin v. Löwis expressed, that as a beginner I didn't read too much into the text at first because I was more concerned with trying out the examples and getting used to writing the code and such. I would also say that, I wasn't too bothered if the guide never went into too much detail about all the terms it was mentioning, it isn't after all a definitive guide on sockets, but the terms can always be googled later if one so wished. I wholeheartedly disagree with removing it, that would be a real shame and I dislike the idea of moving it to the wiki (I cannot even remember ever visiting the wiki). I may not be a Python Guru but I think my "n00bishness" helps in this particular discussion and I would say I would have to agree to an improvement over the suggested alternatives. Craig ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Help requested for Python ISO Standard
Skip: Thanks, appreciate the link I've checked them all out and some may be useful to my task. Regards, Kevin Coyne Cell: 703.901.6774 > Date: Mon, 6 Jun 2011 15:36:11 -0500 > To: [email protected] > CC: [email protected]; [email protected]; [email protected] > Subject: Re: [Python-Dev] Help requested for Python ISO Standard > From: [email protected] > > > kevin> I am working on an ISO Annex of Vulnerabilities for the Python > kevin> language and am asking for help getting a list of language > kevin> features that exhibit: > > kevin> unspecified behavior, undefined behavior, or implementation > kevin> defined behavior. I am also searching for a list of deprecated > kevin> features. > > One place to search: > > http://svn.python.org/projects/python/branches/py3k/Lib/test/crashers/ > > -- > Skip Montanaro - [email protected] - http://www.smontanaro.net/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Help requested for Python ISO Standard
On Tue, Jun 7, 2011 at 8:14 AM, kevin coyne wrote: > Skip: > Thanks, appreciate the link I've checked them all out and some may be > useful to my task. Another two scans to try would be to look for "cpython" in the test suite and "impl-detail" in the documentation. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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: Issue #12040: Expose a new attribute `sentinel` on instances of
On Tue, Jun 7, 2011 at 3:36 AM, antoine.pitrou
wrote:
> + @property
> + def sentinel(self):
> + '''
> + Return a file descriptor (Unix) or handle (Windows) suitable for
> + waiting for process termination.
> + '''
> + try:
> + return self._sentinel
> + except AttributeError:
> + raise ValueError("process not started")
> +
We should probably follow this model for threading.Thread.ident as
well (i.e. throwing an exception rather than returning None if the
thread hasn't been started yet).
Also, for runtime state errors, we tend to use RuntimeError rather
than ValueError (e.g. see the errors thrown by
contextlib._GeneratorContextManager)
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Remove some extraneous parentheses and swap the comparison order to
On 06/07/11 05:20, brett.cannon wrote:
> http://hg.python.org/cpython/rev/fc282e375703
> changeset: 70695:fc282e375703
> user:Brett Cannon
> date:Mon Jun 06 20:20:36 2011 -0700
> summary:
> Remove some extraneous parentheses and swap the comparison order to
> prevent accidental assignment.
>
> Silences a warning from LLVM/clang 2.9.
Swapping the comparison order here seems a bit inconsistent to me. There are
lots of others around (e.g. "len == 0" in the patch context below). Why is
this one so special?
I think that another developer even got told off once for these kinds of
comparisons.
I hope the Clang warning is only about the parentheses.
Georg
> files:
> Modules/arraymodule.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>
> diff --git a/Modules/arraymodule.c b/Modules/arraymodule.c
> --- a/Modules/arraymodule.c
> +++ b/Modules/arraymodule.c
> @@ -2091,7 +2091,7 @@
> if (len == 0) {
> return PyUnicode_FromFormat("array('%c')", (int)typecode);
> }
> -if ((typecode == 'u'))
> +if ('u' == typecode)
> v = array_tounicode(a, NULL);
> else
> v = array_tolist(a, NULL);
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
