Re: [Python-Dev] Suggested addition to PEP 8 for context managers
On Apr 18, 2012, at 1:38 PM, Guido van Rossum wrote: > > Let's change this to something more reasonable, e.g. > > """ > If operators with different priorities are used, consider adding > whitespace around the operators with the lowest priority(ies). This is > very much to taste, however, never use more than one space, and always > have the same amount of whitespace on both sides of a binary operator. > """ +1 Raymond___ 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] Suggested addition to PEP 8 for context managers
On Wed, Apr 18, 2012 at 8:14 PM, Chris Angelico wrote: > On Thu, Apr 19, 2012 at 1:06 PM, Eli Bendersky wrote: >> (quoting GvR) >>> Let's change this to something more reasonable, e.g. >>> >>> """ >>> If operators with different priorities are used, consider adding >>> whitespace around the operators with the lowest priority(ies). This is >>> very much to taste, however, never use more than one space, and always >>> have the same amount of whitespace on both sides of a binary operator. >>> """ >> >> +1, a very welcome change to a piece of PEP8 I've always felt >> uncomfortable with. Tiny nitpick: I'd just replace the comma following >> "however" with a period or semicolon. > > Following or preceding? Either works, but there's a slight shift of > meaning depending on which punctuation gets the upgrade. What was the > original intent of the paragraph? I meant the semicolon to be before 'however'. -- --Guido van Rossum (python.org/~guido) ___ 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] Suggested addition to PEP 8 for context managers
On Thu, Apr 19, 2012 at 1:06 PM, Eli Bendersky wrote: > (quoting GvR) >> Let's change this to something more reasonable, e.g. >> >> """ >> If operators with different priorities are used, consider adding >> whitespace around the operators with the lowest priority(ies). This is >> very much to taste, however, never use more than one space, and always >> have the same amount of whitespace on both sides of a binary operator. >> """ > > +1, a very welcome change to a piece of PEP8 I've always felt > uncomfortable with. Tiny nitpick: I'd just replace the comma following > "however" with a period or semicolon. Following or preceding? Either works, but there's a slight shift of meaning depending on which punctuation gets the upgrade. What was the original intent of the paragraph? Chris Angelico ___ 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] Suggested addition to PEP 8 for context managers
>>> Quoting from
>>> http://www.python.org/dev/peps/pep-0008/#other-recommendations
>>> (with elision):
>>>
>>> Use spaces around arithmetic operators:
>>> No:
>>> i=i+1
>>> submitted +=1
>>> x = x*2 - 1
>>> hypot2 = x*x + y*y
>>> c = (a+b) * (a-b)
>>>
>>> End quote.
>>
>>
>> I agree that this could be reworded. Especially when the operands are
>> as short as in the examples, the last three "No"s read better to me than
>> the "Yes" entries. In this case, spacing serves for visually grouping
>> expressions by precedence, which otherwise could also be indicated by
>> (semantically unnecessary) parens.
>
> Indeed. I don't know who put that in, it wasn't me.
>
>> But in all cases discussed here, PEP8 should not be seen as a law.
>> Its second section ("A Foolish Consistency is the Hobgoblin of Little
>> Minds") is quite prominent for a reason.
>
> I think whoever put that blanket rule in the PEP fell prey to this.
>
> Let's change this to something more reasonable, e.g.
>
> """
> If operators with different priorities are used, consider adding
> whitespace around the operators with the lowest priority(ies). This is
> very much to taste, however, never use more than one space, and always
> have the same amount of whitespace on both sides of a binary operator.
> """
+1, a very welcome change to a piece of PEP8 I've always felt
uncomfortable with. Tiny nitpick: I'd just replace the comma following
"however" with a period or semicolon.
Eli
___
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] PEP 418: Add monotonic time, performance counter and process time functions
> That was nice of you. In return, I'll go over the PEP to check that > usage is appropriate (eg, in some places "resolution" was used in the > sense of computer science's "precision" == reported digits). Oh, this is very likely :-) > BTW, this not a criticism, you did a great job of putting all that > information together. But it's worth checking and that is best done > by a second pair of eyes. What? The subject of the initial mail contains [RFC]: I posted to PEP to get as many reviews as possible! I know that it is not a criticism :-) Victor ___ 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] __hash__ documentation
On Thu, Apr 19, 2012 at 11:35 AM, Stephen J. Turnbull wrote: > On Thu, Apr 19, 2012 at 5:16 AM, Ned Deily wrote: > >>> Ethan Furman wrote: > >>> > How does one follow the bug tracker? > > [informative and useful answers elided] > > I would like to summarize this thread and add it to the dev > documentation. Where should it go? (If nobody bothers to answer, > I'll assume the answer is "figure it out for yourself" and do that. > The only answers I can't figure out for myself are "Bad idea, don't" > and "I did it already, don't". :-) Separating out a dedicated "Issue Tracker" section from the general "Mailing Lists" section here would probably be a good place to start: http://docs.python.org/devguide/communication.html A new entry in the Communications section of the dev FAQ that references the updated section may also be worthwhile: http://docs.python.org/devguide/faq.html#communications 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] PEP 418: Add monotonic time, performance counter and process time functions
On Thu, Apr 19, 2012 at 8:15 AM, Victor Stinner wrote: > Well, I asked on IRC what I should do for these definitions because > I'm too tired to decide what to do. [[...]] I replaced these definitions with > yours. That was nice of you. In return, I'll go over the PEP to check that usage is appropriate (eg, in some places "resolution" was used in the sense of computer science's "precision" == reported digits). Please give me 24 hours. BTW, this not a criticism, you did a great job of putting all that information together. But it's worth checking and that is best done by a second pair of eyes. Thanks for all your work on this! Regards, Steve ___ 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] __hash__ documentation
On Thu, Apr 19, 2012 at 5:16 AM, Ned Deily wrote: >> Ethan Furman wrote: >> > How does one follow the bug tracker? [informative and useful answers elided] I would like to summarize this thread and add it to the dev documentation. Where should it go? (If nobody bothers to answer, I'll assume the answer is "figure it out for yourself" and do that. The only answers I can't figure out for myself are "Bad idea, don't" and "I did it already, don't". :-) Steve ___ 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] Highlighting reference-stealing APIs [was Re: cpython: Fix email post-commit review comments.]
On Thu, Apr 19, 2012 at 11:04 AM, Gregory P. Smith wrote: > +1 Adding these annotations and setting up a buildbot that builds using > cpychecker would be a great. Even without the extra annotations, running cpychecker on at least one of the buildbots might be helpful. I'm in the process of setting up a buildbot for RHEL 6, once I get it up and running normally, I'll look into what it would take to install and enable cpychecker for the builds. (Or, alternatively, I may make it a separate cron job, similar to the daily refcount leak detection run). 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] cpython: Fix email post-commit review comments.
On Thu, Apr 19, 2012 at 12:21 AM, Antoine Pitrou wrote: > I don't think INCREFs were necessary, actually. > PyDict_SetItemString doesn't steal a reference. Yes, I was tired when that checkin went by and my brain didn't register that the function was otherwise using borrowed refs for name and path, so it was also correct to use borrowed refs to Py_None. I should have been less cryptic and written out my full question "Should there be Py_INCREF's here?" rather than using the shorthand (i genuinely wasn't sure at the time, but that wasn't clear from what I wrote). > (and here we see why reference-stealing APIs are a nuisance: because > you never know in advance whether a function will steal a reference or > not, and you have to read the docs for each and every C API call you > make) Yeah, it would have been nice if there was an explicit hint in the API names when reference stealing was involved, but I guess it's far too late now :( Regards, 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] Highlighting reference-stealing APIs [was Re: cpython: Fix email post-commit review comments.]
On Wed, Apr 18, 2012 at 5:01 PM, David Malcolm wrote: > On Thu, 2012-04-19 at 10:48 +1200, Greg Ewing wrote: > > Antoine Pitrou wrote: > > > > > (and here we see why reference-stealing APIs are a nuisance: because > > > you never know in advance whether a function will steal a reference or > > > not, and you have to read the docs for each and every C API call you > > > make) > > > > Fortunately, they're very rare, so you don't encounter > > them often. > > > > Unfortunately, they're very rare, so you're all the more > > likely to forget about them and get bitten. > > > > Functions with ref-stealing APIs really ought to have > > a naming convention that makes them stand out and remind > > you to consult the documentation. > FWIW my refcount static analyzer adds various new compile-time > attributes to gcc: > > http://gcc-python-plugin.readthedocs.org/en/latest/cpychecker.html#marking-functions-that-steal-references-to-their-arguments > so you can write declarations like these: > > extern void bar(int i, PyObject *obj, int j, PyObject *other) > CPYCHECKER_STEALS_REFERENCE_TO_ARG(2) > CPYCHECKER_STEALS_REFERENCE_TO_ARG(4); > > There's a similar attribute for functions that return borrowed > references: > > PyObject *foo(void) >CPYCHECKER_RETURNS_BORROWED_REF; > > Perhaps we should add such attributes to the headers for Python 3.3? > (perhaps with a different naming convention?) > +1 Adding these annotations and setting up a buildbot that builds using cpychecker would be a great. -gps > > Hope this is helpful > Dave > > ___ > 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/greg%40krypto.org > ___ 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] cpython: Fix email post-commit review comments.
On 19/04/12 11:22, Tres Seaver wrote: Maybe we should mandate that their names end with '_rtfm'. +1 -- Greg ___ 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] Suggested addition to PEP 8 for context managers
Hrvoje Niksic wrote: The same oddity occurs with expressions in kwargs calls: func(pos1, pos2, keyword=foo + bar) I find myself wanting to add parentheses arround the + to make the code clearer. Then why don't you? In the above example, spaces around the + are not only optional but discouraged, this would be preferred: func(pos1, pos2, keyword=foo+bar) but if you insist on using spaces (perhaps because it is part of a larger expression) just use parentheses. func(pos1, pos2, keyword=(foo*spam*ham*eggs + bar/spam**cheese)) Strictly speaking they're not needed, but if they make it easier to read (and I think they do) then why would you not use them? -- Steven ___ 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] Highlighting reference-stealing APIs [was Re: cpython: Fix email post-commit review comments.]
On Thu, 2012-04-19 at 10:48 +1200, Greg Ewing wrote: > Antoine Pitrou wrote: > > > (and here we see why reference-stealing APIs are a nuisance: because > > you never know in advance whether a function will steal a reference or > > not, and you have to read the docs for each and every C API call you > > make) > > Fortunately, they're very rare, so you don't encounter > them often. > > Unfortunately, they're very rare, so you're all the more > likely to forget about them and get bitten. > > Functions with ref-stealing APIs really ought to have > a naming convention that makes them stand out and remind > you to consult the documentation. FWIW my refcount static analyzer adds various new compile-time attributes to gcc: http://gcc-python-plugin.readthedocs.org/en/latest/cpychecker.html#marking-functions-that-steal-references-to-their-arguments so you can write declarations like these: extern void bar(int i, PyObject *obj, int j, PyObject *other) CPYCHECKER_STEALS_REFERENCE_TO_ARG(2) CPYCHECKER_STEALS_REFERENCE_TO_ARG(4); There's a similar attribute for functions that return borrowed references: PyObject *foo(void) CPYCHECKER_RETURNS_BORROWED_REF; Perhaps we should add such attributes to the headers for Python 3.3? (perhaps with a different naming convention?) Hope this is helpful Dave ___ 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] cpython: Fix email post-commit review comments.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/18/2012 06:48 PM, Greg Ewing wrote: > Functions with ref-stealing APIs really ought to have a naming > convention that makes them stand out and remind you to consult the > documentation. Maybe we should mandate that their names end with '_rtfm'. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+PTLwACgkQ+gerLs4ltQ5YgACg17rdlCVf8YJmGoYP2eANC8ya RhoAnimJr/5FzR59IELHAyhdXOO1c+uJ =uWHZ -END PGP SIGNATURE- ___ 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] PEP 418: Add monotonic time, performance counter and process time functions
>> If anyone is motivated to write a perfect (or at least better) glossary, >> please do it! > > We don't want a perfect glossary, we want one we agree on, that > defines terms consistently with the way they're used in the PEP. > However, what I read in this thread is that the PEP protagonist > doesn't feel qualified or motivated to maintain the glossary, and > others posting that surely we agree on what we're talking about even > though the definitions in the PEP are controversial and at least one > (resolution) is close to meaningless in actual use. It bothers me > that we are writing code without having agreement about the terms that > define what it's trying to accomplish. Especially when an important > subset of users who I think are likely to care (viz, the scientific > and engineering community) seems likely to use different definitions. Well, I asked on IRC what I should do for these definitions because I'm too tired to decide what to do. Ezio Melotti (Taggnostr) and R. David Murray (bitdancer) prefer your definition over the current definitions of accuracy, precision and resolution in the PEP. So I replaced these definitions with yours. Victor ___ 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] cpython: Fix email post-commit review comments.
Antoine Pitrou wrote: (and here we see why reference-stealing APIs are a nuisance: because you never know in advance whether a function will steal a reference or not, and you have to read the docs for each and every C API call you make) Fortunately, they're very rare, so you don't encounter them often. Unfortunately, they're very rare, so you're all the more likely to forget about them and get bitten. Functions with ref-stealing APIs really ought to have a naming convention that makes them stand out and remind you to consult the documentation. -- Greg ___ 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] cpython: Fix email post-commit review comments.
On Wed, Apr 18, 2012 at 8:21 AM, Antoine Pitrou wrote: > (and here we see why reference-stealing APIs are a nuisance: because > you never know in advance whether a function will steal a reference or > not, and you have to read the docs for each and every C API call you > make) +1 -eric ___ 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] __hash__ documentation
In article <20120418211404.2700d...@pitrou.net>, Antoine Pitrou wrote: > On Wed, 18 Apr 2012 12:19:39 -0700 > Ethan Furman wrote: > > Brian Curtin wrote: > > > On Wed, Apr 18, 2012 at 13:07, Ethan Furman wrote: > > > Those who follow the bug tracker will see the issue and act > > > accordingly. > > > > How does one follow the bug tracker? > > Checking it frequently is a possibility. > Reading http://mail.python.org/mailman/listinfo/new-bugs-announce is > another. Another is following changes via the gmane.org mirror of the bugs list. gmane.org provides web, NNTP newsreader, and RSS feeds of all of the mailing lists mirrored there: http://dir.gmane.org/gmane.comp.python.bugs Many of the other python.org-hosted mailing lists are mirrored at gmane as well. -- Ned Deily, n...@acm.org ___ 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] webbrowser no longer support 'internet-config' on Mac
In article <20120418140936.21dd7250...@webabinitio.net>, "R. David Murray" wrote: > Please submit a bug report at bugs.python.org. Bugs posted to this > mailing list tend to get forgotten unless a tracker issue is created. > > On Wed, 18 Apr 2012 20:54:28 +0800, Leo wrote: > > The doc says supported as in > > http://docs.python.org/library/webbrowser.html > > > > but the code has been deleted in > > http://hg.python.org/cpython/rev/66b3eda6283f Thanks for the report: the documentation for the obsolete internet-config option is now removed (2.7 - dd2b579a, 3.2 - 292cbd59dbe0, 3.3 - b5e6cbacd6ab). -- Ned Deily, n...@acm.org ___ 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] PEP 418: Add monotonic time, performance counter and process time functions
On Wed, 18 Apr 2012 15:50:13 -0400, Terry Reedy wrote: > On 4/18/2012 2:45 AM, Stephen J. Turnbull wrote: > > On Wed, Apr 18, 2012 at 8:25 AM, Victor Stinner > > wrote: > > > >> Ok ok, resolution / accuracy / precision are confusing (or at least > >> not well known concepts). > > > > Maybe not to us, but in fields like astronomy and mechanical > > engineering there are commonly accepted definitions: > > > > Resolution: the smallest difference between two physical values that > > results in a different measurement by a given instrument. > > > > Precision: the amount of deviation among measurements of the same > > physical value by a single instrument. > > > > Accuracy: the amount of deviation of measurements by a given > > instrument from true values. > > These are standard definitions in US English that I learned in physics > and statistics decades ago. My problem was that I was confusing this definition of precision with the "precision" of the computer representation of the number (that is, the number of digits in the returned result). --David ___ 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] __hash__ documentation
On 4/18/2012 3:19 PM, Ethan Furman wrote: Brian Curtin wrote: On Wed, Apr 18, 2012 at 13:07, Ethan Furman wrote: Those who follow the bug tracker will see the issue and act accordingly. How does one follow the bug tracker? I look at the Friday summary, paying particular attention to issues with no responses from those who follow it more frequently. -- Terry Jan Reedy ___ 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] PEP 418: Add monotonic time, performance counter and process time functions
On 4/18/2012 2:45 AM, Stephen J. Turnbull wrote: On Wed, Apr 18, 2012 at 8:25 AM, Victor Stinner wrote: Ok ok, resolution / accuracy / precision are confusing (or at least not well known concepts). Maybe not to us, but in fields like astronomy and mechanical engineering there are commonly accepted definitions: Resolution: the smallest difference between two physical values that results in a different measurement by a given instrument. Precision: the amount of deviation among measurements of the same physical value by a single instrument. Accuracy: the amount of deviation of measurements by a given instrument from true values. These are standard definitions in US English that I learned in physics and statistics decades ago. -- Terry Jan Reedy ___ 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] __hash__ documentation
Brian Curtin wrote: On Wed, Apr 18, 2012 at 13:07, Ethan Furman wrote: http://bugs.python.org/issue14617 Patch attached to issue. Can I request that you not immediately post issues to python-dev? Those who follow the bug tracker will see the issue and act accordingly. (unless I missed some explicit request that this be posted here, in which case I apologize) No problem, still learning how things work. :) ~Ethan~ ___ 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] __hash__ documentation
Am 18.04.2012 21:19, schrieb Ethan Furman: > Brian Curtin wrote: >> On Wed, Apr 18, 2012 at 13:07, Ethan Furman wrote: >> Those who follow the bug tracker will see the issue and act >> accordingly. > > How does one follow the bug tracker? I do by subscribing to new-bugs-announce. 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
Re: [Python-Dev] cpython: Issue #11750: The Windows API functions scattered in the _subprocess and
On Wed, 18 Apr 2012 21:29:00 +0200 "Martin v. Löwis" wrote: > Am 18.04.2012 20:52, schrieb antoine.pitrou: > > http://hg.python.org/cpython/rev/f3a27d11101a > > changeset: 76405:f3a27d11101a > > user:Antoine Pitrou > > date:Wed Apr 18 20:51:15 2012 +0200 > > summary: > > Issue #11750: The Windows API functions scattered in the _subprocess and > > _multiprocessing.win32 modules now live in a single module "_winapi". > > Patch by sbt. > > Can we use Real Names, please? Do we have a policy about that? sbt seems happy using a pseudonym (and I personally don't have a problem with it). Regards Antoine. ___ 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: Issue #11750: The Windows API functions scattered in the _subprocess and
Am 18.04.2012 20:52, schrieb antoine.pitrou: > http://hg.python.org/cpython/rev/f3a27d11101a > changeset: 76405:f3a27d11101a > user:Antoine Pitrou > date:Wed Apr 18 20:51:15 2012 +0200 > summary: > Issue #11750: The Windows API functions scattered in the _subprocess and > _multiprocessing.win32 modules now live in a single module "_winapi". > Patch by sbt. Can we use Real Names, please? 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
Re: [Python-Dev] __hash__ documentation
On Wed, 18 Apr 2012 12:19:39 -0700 Ethan Furman wrote: > Brian Curtin wrote: > > On Wed, Apr 18, 2012 at 13:07, Ethan Furman wrote: > > Those who follow the bug tracker will see the issue and act > > accordingly. > > How does one follow the bug tracker? Checking it frequently is a possibility. Reading http://mail.python.org/mailman/listinfo/new-bugs-announce is another. In any case, annoucing new issues on python-dev would only flood the mailing-list and infuriate all readers. You should keep it to really important issues, or if you have a specific question to ask. Regards Antoine. ___ 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] __hash__ documentation
2012/4/18 Ethan Furman : > Brian Curtin wrote: >> >> On Wed, Apr 18, 2012 at 13:07, Ethan Furman wrote: >> Those who follow the bug tracker will see the issue and act >> accordingly. > > > How does one follow the bug tracker? One checks occasionally to see if anything interesting has popped up or, for the insane, subscribes to python-bugs. -- 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] __hash__ documentation
Brian Curtin wrote: On Wed, Apr 18, 2012 at 13:07, Ethan Furman wrote: Those who follow the bug tracker will see the issue and act accordingly. How does one follow the bug tracker? ~Ethan~ ___ 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] __hash__ documentation
On Wed, Apr 18, 2012 at 13:07, Ethan Furman wrote: > http://bugs.python.org/issue14617 > > Patch attached to issue. Can I request that you not immediately post issues to python-dev? Those who follow the bug tracker will see the issue and act accordingly. (unless I missed some explicit request that this be posted here, in which case I apologize) ___ 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] __hash__ documentation
http://bugs.python.org/issue14617 Patch attached to issue. ~Ethan~ ___ 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] Suggested addition to PEP 8 for context managers
On Wed, Apr 18, 2012 at 9:25 AM, Georg Brandl wrote:
> On 18.04.2012 17:47, Chris Angelico wrote:
>>
>> On Thu, Apr 19, 2012 at 12:47 AM, Guido van Rossum
>> wrote:
>>>
>>> I don't believe PEP 8 requires whitespace around all binary operators.
>>> Where do you read that?
>>
>>
>> Quoting from
>> http://www.python.org/dev/peps/pep-0008/#other-recommendations
>> (with elision):
>>
>> Use spaces around arithmetic operators:
>> No:
>> i=i+1
>> submitted +=1
>> x = x*2 - 1
>> hypot2 = x*x + y*y
>> c = (a+b) * (a-b)
>>
>> End quote.
>
>
> I agree that this could be reworded. Especially when the operands are
> as short as in the examples, the last three "No"s read better to me than
> the "Yes" entries. In this case, spacing serves for visually grouping
> expressions by precedence, which otherwise could also be indicated by
> (semantically unnecessary) parens.
Indeed. I don't know who put that in, it wasn't me.
> But in all cases discussed here, PEP8 should not be seen as a law.
> Its second section ("A Foolish Consistency is the Hobgoblin of Little
> Minds") is quite prominent for a reason.
I think whoever put that blanket rule in the PEP fell prey to this.
Let's change this to something more reasonable, e.g.
"""
If operators with different priorities are used, consider adding
whitespace around the operators with the lowest priority(ies). This is
very much to taste, however, never use more than one space, and always
have the same amount of whitespace on both sides of a binary operator.
"""
--
--Guido van Rossum (python.org/~guido)
___
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] Suggested addition to PEP 8 for context managers
On 18.04.2012 17:47, Chris Angelico wrote:
On Thu, Apr 19, 2012 at 12:47 AM, Guido van Rossum wrote:
I don't believe PEP 8 requires whitespace around all binary operators.
Where do you read that?
Quoting from http://www.python.org/dev/peps/pep-0008/#other-recommendations
(with elision):
Use spaces around arithmetic operators:
No:
i=i+1
submitted +=1
x = x*2 - 1
hypot2 = x*x + y*y
c = (a+b) * (a-b)
End quote.
I agree that this could be reworded. Especially when the operands are
as short as in the examples, the last three "No"s read better to me than
the "Yes" entries. In this case, spacing serves for visually grouping
expressions by precedence, which otherwise could also be indicated by
(semantically unnecessary) parens.
But in all cases discussed here, PEP8 should not be seen as a law.
Its second section ("A Foolish Consistency is the Hobgoblin of Little
Minds") is quite prominent for a reason.
Georg
___
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] Suggested addition to PEP 8 for context managers
On Thu, Apr 19, 2012 at 12:47 AM, Guido van Rossum wrote: > I don't believe PEP 8 requires whitespace around all binary operators. > Where do you read that? Quoting from http://www.python.org/dev/peps/pep-0008/#other-recommendations (with elision): Use spaces around arithmetic operators: No: i=i+1 submitted +=1 x = x*2 - 1 hypot2 = x*x + y*y c = (a+b) * (a-b) End quote. In my code, whether Python or any other language, I tend to follow the principle that whitespace is completely optional in these expressions, but if spaces surround any operator, they should (generally) also surround all operators of lower precedence in the same expression. So I would quite happily accept all of the expressions above (except 'submitted', which is inconsistent), but would prefer not to see something like: c=(a + b)*(a - b) which is also forbidden by PEP 8. ChrisA ___ 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] Suggested addition to PEP 8 for context managers
On Wed, Apr 18, 2012 at 1:29 AM, Floris Bruynooghe wrote: > And since this is OT by now, one of the other pep8 annoyances I > have[0] is the blanket whitespace around arithmetic operators, > including **. To me the first just looks ugly: > 1024 ** 2 1024**2 > > Certainly when the expressions are larger. I don't believe PEP 8 requires whitespace around all binary operators. Where do you read that? -- --Guido van Rossum (python.org/~guido) ___ 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] cpython: Fix email post-commit review comments.
On Wed, 18 Apr 2012 15:31:10 +0200 brian.curtin wrote: > http://hg.python.org/cpython/rev/bf23a6c215f6 > changeset: 76388:bf23a6c215f6 > parent: 76385:6762b943ee59 > user:Brian Curtin > date:Wed Apr 18 08:30:51 2012 -0500 > summary: > Fix email post-commit review comments. > > Add INCREFs, fix args->kwargs, and a second args==NULL check was removed, > left over from a merger with another function. Instead, checking msg==NULL > does what that used to do in a roundabout way. I don't think INCREFs were necessary, actually. PyDict_SetItemString doesn't steal a reference. (and here we see why reference-stealing APIs are a nuisance: because you never know in advance whether a function will steal a reference or not, and you have to read the docs for each and every C API call you make) Regards Antoine. ___ 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] webbrowser no longer support 'internet-config' on Mac
Please file a bug report at bugs.python.org so this isn't lost. On Wed, Apr 18, 2012 at 08:54, Leo wrote: > The doc says supported as in > http://docs.python.org/library/webbrowser.html > > but the code has been deleted in > http://hg.python.org/cpython/rev/66b3eda6283f > > Leo > > ___ > 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/brett%40python.org > ___ 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] webbrowser no longer support 'internet-config' on Mac
Please submit a bug report at bugs.python.org. Bugs posted to this mailing list tend to get forgotten unless a tracker issue is created. On Wed, 18 Apr 2012 20:54:28 +0800, Leo wrote: > The doc says supported as in > http://docs.python.org/library/webbrowser.html > > but the code has been deleted in > http://hg.python.org/cpython/rev/66b3eda6283f > > Leo > > ___ > 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/rdmurray%40bitdance.com ___ 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: Fix email post-commit review comments.
We're seeing segfuilts on the buildbots now. Example:
http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%20Shared%203.x/builds/5715
On Wed, 18 Apr 2012 23:39:34 +1000, Nick Coghlan wrote:
> On Wed, Apr 18, 2012 at 11:31 PM, brian.curtin
> wrote:
> > - Â Â if (name == NULL)
> > + Â Â if (name == NULL) {
> > + Â Â Â Â Py_INCREF(Py_None);
> > Â Â Â Â name = Py_None;
> > + Â Â }
>
> A slightly more traditional way to write that would be:
>
> name = Py_None;
> Py_INCREF(name);
>
> > - Â Â if (path == NULL)
> > + Â Â if (path == NULL) {
> > + Â Â Â Â Py_INCREF(Py_None);
> > Â Â Â Â path = Py_None;
> > + Â Â }
>
> Ditto.
>
> >
> > Â Â Py_INCREF(msg);
> > - Â Â PyTuple_SetItem(args, 0, msg);
> > + Â Â PyTuple_SetItem(args, 0, NULL);//msg);
>
> However, *this* looks a lot more suspicious... accidental commit of
> debugging code?
>
> (if not for spotting this last problem, I wouldn't have even mentioned
> the first two)
>
> 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/rdmurray%40bitdance.com
___
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] PEP 418: Add monotonic time, performance counter and process time functions
On Wed, Apr 18, 2012 at 7:29 PM, Victor Stinner wrote: > If anyone is motivated to write a perfect (or at least better) glossary, > please do it! We don't want a perfect glossary, we want one we agree on, that defines terms consistently with the way they're used in the PEP. However, what I read in this thread is that the PEP protagonist doesn't feel qualified or motivated to maintain the glossary, and others posting that surely we agree on what we're talking about even though the definitions in the PEP are controversial and at least one (resolution) is close to meaningless in actual use. It bothers me that we are writing code without having agreement about the terms that define what it's trying to accomplish. Especially when an important subset of users who I think are likely to care (viz, the scientific and engineering community) seems likely to use different definitions. Has anybody asked people on the scipy channels what they think about all this? > It already contains a link to the Wikipedia article "Accuracy_and_precision". Well, its definitions differ of precision and resolution differ from the PEP's. I'm disturbed that the PEP does not remark about this despite citing it. ___ 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: Fix email post-commit review comments.
On Wed, Apr 18, 2012 at 11:31 PM, brian.curtin
wrote:
> - if (name == NULL)
> + if (name == NULL) {
> + Py_INCREF(Py_None);
> name = Py_None;
> + }
A slightly more traditional way to write that would be:
name = Py_None;
Py_INCREF(name);
> - if (path == NULL)
> + if (path == NULL) {
> + Py_INCREF(Py_None);
> path = Py_None;
> + }
Ditto.
>
> Py_INCREF(msg);
> - PyTuple_SetItem(args, 0, msg);
> + PyTuple_SetItem(args, 0, NULL);//msg);
However, *this* looks a lot more suspicious... accidental commit of
debugging code?
(if not for spotting this last problem, I wouldn't have even mentioned
the first two)
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
[Python-Dev] webbrowser no longer support 'internet-config' on Mac
The doc says supported as in http://docs.python.org/library/webbrowser.html but the code has been deleted in http://hg.python.org/cpython/rev/66b3eda6283f Leo ___ 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] Setting up a RHEL6 buildbot
On Fri, Mar 23, 2012 at 1:48 PM, Nick Coghlan wrote: > I'm looking into getting a RHEL6 system set up to add to the buildbot > fleet. This is getting closer to being ready to go. Could one of the BB admins contact me off-list to set up the slave name and password? 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: Fix #14600. Correct reference handling and naming of ImportError convenience
On Wed, Apr 18, 2012 at 09:19:03PM +1000, Nick Coghlan wrote: > On Wed, Apr 18, 2012 at 7:57 AM, brian.curtin > wrote: > > diff --git a/Python/errors.c b/Python/errors.c > > --- a/Python/errors.c > > +++ b/Python/errors.c > > @@ -586,50 +586,43 @@ > > + args = PyTuple_New(1); > > + if (args == NULL) > > +return NULL; > > + > > + kwargs = PyDict_New(); > > + if (args == NULL) > > +return NULL; Shouldn't the second test be if (kwargs == NULL) ??? Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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: Fix #14600. Correct reference handling and naming of ImportError convenience
On Wed, Apr 18, 2012 at 7:57 AM, brian.curtin
wrote:
> diff --git a/Python/errors.c b/Python/errors.c
> --- a/Python/errors.c
> +++ b/Python/errors.c
> @@ -586,50 +586,43 @@
> #endif /* MS_WINDOWS */
>
> PyObject *
> -PyErr_SetExcWithArgsKwargs(PyObject *exc, PyObject *args, PyObject *kwargs)
> +PyErr_SetImportError(PyObject *msg, PyObject *name, PyObject *path)
> {
> - PyObject *val;
> + PyObject *args, *kwargs, *error;
> +
> + args = PyTuple_New(1);
> + if (args == NULL)
> + return NULL;
> +
> + kwargs = PyDict_New();
> + if (args == NULL)
> + return NULL;
> +
> + if (name == NULL)
> + name = Py_None;
> +
> + if (path == NULL)
> + path = Py_None;
Py_INCREF's?
Regards,
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] PEP 418: Add monotonic time, performance counter and process time functions
>> Ok ok, resolution / accuracy / precision are confusing (or at least >> not well known concepts). > > Maybe not to us, but in fields like astronomy and mechanical > engineering there are commonly accepted definitions: I was just talking of the name of the time.perf_counter() function: "perf_counter" vs "high_precision" vs "high_resolution" (or even "highres") names. For the defintion of these words, see the Glossary in the PEP. http://www.python.org/dev/peps/pep-0418/#glossary It already contains a link to the Wikipedia article "Accuracy_and_precision". I don't want to spend days on this glossary. If anyone is motivated to write a perfect (or at least better) glossary, please do it! And send me the diff of the pep-0418.txt file. I don't really feel qualified (nor motivated) to write/maintain such glossary. Victor ___ 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] Suggested addition to PEP 8 for context managers
On 17 April 2012 16:36, Barry Warsaw wrote: > On Apr 17, 2012, at 08:25 AM, R. David Murray wrote: > >>On Tue, 17 Apr 2012 08:53:43 +0200, Matej Cepl wrote: >>> On 16.4.2012 18:10, Nam Nguyen wrote: >>> > a_list[pos + 1 : -1] >>> >>> or other way around >>> >>> a_list[pos+1:-1] >> >> >>That's what I always use. No spaces inside the brackets for me :) >> >>If the expression gets unreadable that way, factor it out. Ditto here. And since this is OT by now, one of the other pep8 annoyances I have[0] is the blanket whitespace around arithmetic operators, including **. To me the first just looks ugly: >>> 1024 ** 2 >>> 1024**2 Certainly when the expressions are larger. Regards, Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org ___ 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] Suggested addition to PEP 8 for context managers
On 04/17/2012 04:21 PM, Guido van Rossum wrote: I hope that's now what it says about slices -- that was meant for dict displays. For slices it should be symmetrical. In this case I would remove the spaces around the +, but it's okay to add spaces around the : too. It does look odd to have an operator that binds tighter (the +) surrounded by spaces while the operator that binds less tight (:) is not. The same oddity occurs with expressions in kwargs calls: func(pos1, pos2, keyword=foo + bar) I find myself wanting to add parentheses arround the + to make the code clearer. ___ 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] issue 9141, finalizers and gc module
Well, we specifically decided that objects with __del__ methods that are part of a cycle cannot be run. The same reasoning was applied to generators, if they are in a certain state. What makes iobase so special that its 'close' method can be run even if it is part of a cycle? It's a hack, and I find it well-documented in iobase.c. It explains what tricks it has to go through to still invoke methods from tp_del. Invoking methods in tp_clear I find fairly harmless, in comparison. My only concern is that errors are silently ignored. However, I don't think this matters in practice, since io objects typically are not part of cycles, anyway. Why not allow it for all objects, then? It's *allowed* for all objects. Why do you think it is not? It must be opt-in, though. In the IO case, there are certain drawbacks; not being able to report errors is the most prominent one. Any other object implementation will have to evaluate whether to follow the iobase approach, or implement a regular __del__. I personally consider the resurrection in tp_del a much more serious problem, though, as this goes explicitly against the design of the release procedure. For iobase, it's ok since it can evolve along with the rest of the code base. Any third-party author would have to accept that such approach can break from one Python release to the next. I wonder why Python couldn't promise to always invoke tp_clear on GC objects; ISTM that this would remove the need for resurrection in tp_del. At the very least, I think this behaviour (this exception for iobase) merits being explicitly documented. I find all of this well-documented in iobase.c. If you think anything else needs to be said, please submit patches. 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
