[Python-Dev] Issues 9931 and 9055 - test_ttk_guionly and buildbot run as a service
Hi, My buildbot has been failing for some time because of these 2 issues, both related to the fact that tests are hanging when run as a service (and hence have no display to open GUI elements on). Both issues have patches, and as far as I am aware, the patches fix the issues reasonably well. What can I do to move these 2 issues forwards? As things stand, my buildbot is not providing a lot of value on the 3.x branch :-( Thanks, Paul. ___ 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] Removal of Win32 ANSI API
> Additionally: > > d) Over a socket (like the HTTP protocol) -> Bytes. Sure. However, you can't really expect that the bytes you receive over the socket are a meaningful filename on your local Windows installation. So it would be a bug in the application to not decode the bytes that you receive before using them as a file name. In a well-specified network protocol, you would know the encoding of the bytes; IETF recommends to use UTF-8 for all new protocols. Using an UTF-8 string as a filename on Windows will create mojibake. 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] buildbot master update
As you may have noticed: I updated the buildbot master to release 0.8.2. If you notice any problems, please post them here. Slave operators can upgrade their installations at their own pace; buildbot is highly backwards compatible. As a recommendation, I suggest that slaves run at least at the version that is available in Debian stable (currently 0.7.8). 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] bugs.python.org migration complete
bugs.python.org is now on the new hardware. There have been some problems in the migration: the old hardware would start failing before the scheduled migration date, so the migration was done early, causing outage for some people who then the old address in their DNS caches. In addition, there was initially a misconfiguration preventing outgoing IP traffic, particularly preventing outgoing emails from being delivered. This is all fixed now; report any remaining issues to the metatracker. 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] Breaking undocumented API
On 11/11/2010 11:24 PM, Greg Ewing wrote: Nick Coghlan wrote: My personal opinion is that we should be trying to get the standard library to the point where __all__ definitions are unnecessary - if a name isn't in __all__, it should start with an underscore (and if that is true, then the __all__ definition becomes effectively redundant). What about names imported from other modules that are used by the module, but not intended for re-export? How would you prevent them from turning up in help() etc. without using __all__? import foo as _foo I believe I am not the only one who finds that practice ugly, but I find it just as ugly to underscore-ize every non-public helper function. __all__ is there for a reason, let's use it. Maybe help() could automatically ignore stuff not in __all__, or display it but warn the user of non-public identifiers? ___ 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] Breaking undocumented API
Am 11.11.2010 23:15, schrieb Nick Coghlan: If we instead adopt the explicit policy that private APIs are: - imported modules (with the exception of os.path) - any names starting with a leading underscore Then we get the 3 API tiers you describe: core public API in __all__, other public functions and globals without leading underscores, private API with leading underscores (or imported modules). +1 I like this approach *very much*. Let me elaborate: 1. The community knows, understands and accepts _names as private. We need to have _names for private functions and constants because we can change or remove those in later versions. It's very explicit: when the user complains "What, you removed _foo?" we can say "Yes, it was considered an implementation detail *from the start*." And it's hard to beat that argument. It was private from the start. You knew that because the name you called specifies that. If we would be now to proclaim __all__ as a decisive point on what's private and what's not, it makes lives of all Python programmers (I mean the users as well) more complicated. 2. That being said, having help() mark non-underscored names which aren't included in __all__ as private is a good idea, too [1]. I'm a heavy user of interactive API discovery using dir() and help() and this would be definitely welcome. And even for those who don't use those tools, this feature can expose inconsistencies between documentation and code. 3. "import name as _name" or "from x.y import z as _z" is just bad form. There may be valid exceptions but imagine if that would be the default way to do it. Uglier than nights of November. 4. This is why I think considering all imports as private (unless they're in __all__) is a fine example of "practicability beats purity". We could try to conceive a way to expose this information programatically but that's not so important at the moment. [1] As Hrvoje Niksic wrote here: http://mail.python.org/pipermail/python-dev/2010-November/105533.html -- Best regards, Łukasz Langa ___ 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] r86429 - python/branches/py3k/Doc/tools/sphinxext/pyspecific.py
On Fri, Nov 12, 2010 at 3:57 AM, georg.brandl wrote in a commit: > Add a deprecated-removed directive that allows to give the version of removal > for deprecations. This sounds pretty general-purpose rather than Python-specific. Any chance this will move into Sphinx? I know a few projects that like to deprecate things and would use this. :-) -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] Removal of Win32 ANSI API
On Thursday 11 November 2010 23:01:32 you wrote: > > Sure, it will divide the number of lines, of the code specific to > > Windows, by two. > > Can we get most of the code cleanup benefit without the backwards > compatibility risk by doing the decode from 'mbcs' on our side of the > fence? I created PyUnicode_FSDecoder, a ParseTuple converter used to work on unicode paths, instead of bytes paths. On Windows, this converter uses mbcs encoding in strict mode, whereas Windows converter uses replace error handler to decode, and ignore to encode. So I don't think that we should this converter on Windows. > That is, have code that was the C equivalent of: > > arg_is_bytes = not isinstance(arg, str) > if arg_is_bytes: > val = _decode_mbcs(arg) > # Decoding error checking here > else: > val = arg > # Common processing using WIDE API > if arg_is_bytes: > result = _encode_mbcs(wide_result) > # Encoding error checking here > else: > result = wide_result This doesn't make the code shorter, it may be longer than the actual code, and it is less compliant with the Windows native API... 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] Removal of Win32 ANSI API
On Thursday 11 November 2010 21:02:43 Antoine Pitrou wrote: > On Thu, 11 Nov 2010 20:44:52 +0100 > > "Martin v. Löwis" wrote: > > > How do you support cross-platform code using bytes filenames? > > > IIRC, it has already been argued that it was an important feature. Many > > > filesystem-related utilities might prefer to handle filenames in bytes > > > form. > > > > It would be a policy decision. However, I think it is hear-say that > > filesystem-related utilities might prefer byte file names. > > One possible situation is when you receive filenames in bytes form from > an external API or tool (or even the contents of a file). If you don't > know the encoding, keeping the bytes form is obviously recommended. I disagree with you: the filename stored in the binary content/network stream may be encoded with a different code page than the current Windows code page. The application have to decode the filename itself, the application has more information about the right encoding than Windows. Examples: - MKV video stores filenames in utf-8 - ZIP stores filenames in cp437 or utf-8 - tar stores filenames... in the locale encoding (except for PAX format which uses utf-8) - etc. 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] Removal of Win32 ANSI API
On Thursday 11 November 2010 20:50:35 you wrote: > > Even if I hate the MBCS encoding, because it replaces undecodable > > characters by similar glyphs by default, I'm not certain that it is a > > good idea to drop the bytes API. Can it be a problem to port programs > > from Python2 to Python3? Do major Python2 programs/libraries rely on the > > bytes API? > > I don't actually know for a fact, but I expect that the answer is "no". > > The questions is: where do file names typically come from? My guess > is that they come from > a) hard-coded strings in the source code > b) command line arguments/environment variables > c) directory listings > [of course, there are other ways, like GUI input, getcwd(), etc] > > In case a), you have filenames such as ".", e.g. as a parameter to > listdir or walk. These will typically be regular strings in Python 2, > which become Unicode strings in 3. You would actively need to put b"" > prefixes into the code. > > In case b), they will be Unicode strings in Python 3. > > In case c), they will be Unicode strings if the argument is a Unicode > string. So by induction, file names will be typically unicode. The > exception will be libraries/applications which make deliberate attempts > to get byte-oriented file names. Ok, good answer. In this case, I vote +1 to remove completly the ANSI version from all Python modules. I consider the ANSI version has a compatibility layer for old applications written for MS-Dos or early versions of Windows. Even if these APIs are still widely used in C/C++ applications, the wide versions should always be preferred. 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] Removal of Win32 ANSI API
On Fri, 12 Nov 2010 13:13:08 +0100 Victor Stinner wrote: > On Thursday 11 November 2010 21:02:43 Antoine Pitrou wrote: > > On Thu, 11 Nov 2010 20:44:52 +0100 > > > > "Martin v. Löwis" wrote: > > > > How do you support cross-platform code using bytes filenames? > > > > IIRC, it has already been argued that it was an important feature. Many > > > > filesystem-related utilities might prefer to handle filenames in bytes > > > > form. > > > > > > It would be a policy decision. However, I think it is hear-say that > > > filesystem-related utilities might prefer byte file names. > > > > One possible situation is when you receive filenames in bytes form from > > an external API or tool (or even the contents of a file). If you don't > > know the encoding, keeping the bytes form is obviously recommended. > > I disagree with you: the filename stored in the binary content/network stream > may be encoded with a different code page than the current Windows code page. > The application have to decode the filename itself, the application has more > information about the right encoding than Windows. I'm not talking about Windows obviously. POSIX filenames are natively bytes, so if you get a bytes filename from an external source, it makes sense to reuse the bytes form. I think it would be a mistake to allow bytes filenames under POSIX but not under Windows. It makes porting harder. > - tar stores filenames... in the locale encoding (except for PAX format > which > uses utf-8) So bytes filenames are useful at least for tar. I'm sure there are many other cases (actually, most kinds of configuration files containing paths would apply). 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] buildbot master update
On Nov 12, 2010, at 10:29 AM, Martin v. Löwis wrote: >As you may have noticed: I updated the buildbot master to release 0.8.2. >If you notice any problems, please post them here. Pretty! My buildbot seems fine. >Slave operators can upgrade their installations at their own pace; >buildbot is highly backwards compatible. As a recommendation, I suggest >that slaves run at least at the version that is available in Debian >stable (currently 0.7.8). Thanks Martin, for all you do to keep our infrastructure humming along smoothly, including the recent Roundup migration. -Barry signature.asc Description: 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
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2010-11-05 - 2010-11-12) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open2526 (+12) closed 19651 (+54) total 22177 (+66) Open issues with patches: 1050 Issues opened (47) == #9313: distutils error on MSVC older than 8 http://bugs.python.org/issue9313 reopened by eric.araujo #10252: Fix resource warnings in distutils http://bugs.python.org/issue10252 reopened by eric.araujo #10329: trace.py and unicode in Python 3 http://bugs.python.org/issue10329 reopened by belopolsky #10332: Multiprocessing maxtasksperchild results in hang http://bugs.python.org/issue10332 opened by Jimbofbx #10333: Remove ancient backwards compatibility GC API http://bugs.python.org/issue10333 opened by nascheme #10336: test_xmlrpc fails if gzip is not supported by client http://bugs.python.org/issue10336 opened by ocean-city #10338: test_lib2to3 failure on buildbot x86 debian parallel 3.x: node http://bugs.python.org/issue10338 opened by haypo #10339: test_lib2to3 leaks http://bugs.python.org/issue10339 opened by pitrou #10340: asyncore doesn't properly handle EINVAL on OSX http://bugs.python.org/issue10340 opened by giampaolo.rodola #10342: trace module cannot produce coverage reports for zipped module http://bugs.python.org/issue10342 opened by belopolsky #10344: codecs.readline doesn't care buffering=0 http://bugs.python.org/issue10344 opened by Santiago.Piccinini #10348: multiprocessing: use SysV semaphores on FreeBSD http://bugs.python.org/issue10348 opened by haypo #10349: Error in Module/python.c when building on OpenBSD 4.8 http://bugs.python.org/issue10349 opened by pgurumur #10350: errno is read too late http://bugs.python.org/issue10350 opened by hfuru #10351: Add autocompletion for keys in dictionaries http://bugs.python.org/issue10351 opened by Valery.Khamenya #10354: tempfile.template is broken http://bugs.python.org/issue10354 opened by giampaolo.rodola #10355: SpooledTemporaryFile's name property is broken http://bugs.python.org/issue10355 opened by giampaolo.rodola #10356: decimal.py: hash of -1 http://bugs.python.org/issue10356 opened by skrah #10357: ** and "mapping" are poorly defined in python docs http://bugs.python.org/issue10357 opened by Fergal.Daly #10358: Doc styles for print should only use dark colors http://bugs.python.org/issue10358 opened by fdrake #10359: ISO C cleanup http://bugs.python.org/issue10359 opened by hfuru #10360: _weakrefset.WeakSet.__contains__ should not propagate TypeErro http://bugs.python.org/issue10360 opened by tseaver #10362: AttributeError: addinfourl instance has no attribute 'tell' http://bugs.python.org/issue10362 opened by Valentin.Lorentz #10363: Embedded python, handle (memory) leak http://bugs.python.org/issue10363 opened by martind #10364: Color coding fails after running program. http://bugs.python.org/issue10364 opened by Typo #10365: IDLE Crashes on File Open Dialog when code window closed befor http://bugs.python.org/issue10365 opened by william.barr #10366: Remove unneeded '(object)' from 3.x class examples http://bugs.python.org/issue10366 opened by terry.reedy #10367: "python setup.py sdist upload --show-response" can fail with " http://bugs.python.org/issue10367 opened by jcea #10369: tarfile requires an actual file on disc; a file-like object is http://bugs.python.org/issue10369 opened by strombrg #10371: Deprecate trace module undocumented API http://bugs.python.org/issue10371 opened by belopolsky #10373: Setup Script example incorrect http://bugs.python.org/issue10373 opened by lensart #10374: setup.py caches outdated scripts in the build tree http://bugs.python.org/issue10374 opened by gjb1002 #10375: 2to3 print(single argument) http://bugs.python.org/issue10375 opened by hfuru #10376: ZipFile unzip is unbuffered http://bugs.python.org/issue10376 opened by Jimbofbx #10377: cProfile incorrectly labels its output http://bugs.python.org/issue10377 opened by exarkun #10379: locale.format() input regression http://bugs.python.org/issue10379 opened by barry #10381: Add timezone support to datetime C API http://bugs.python.org/issue10381 opened by belopolsky #10382: Command line error marker misplaced on unicode entry http://bugs.python.org/issue10382 opened by belopolsky #10383: test_os leaks under Windows http://bugs.python.org/issue10383 opened by pitrou #10384: SyntaxError should contain exact location of the invalid chara http://bugs.python.org/issue10384 opened by belopolsky #10385: Mark up "subprocess" as module in its doc http://bugs.python.org/issue10385 opened by belopolsky #10388: spwd returning different value depending on privileges http://bugs.python.org/issue10388 opened by giampaolo.rodola #10391: obj2ast's error handling can lead to python crashing with a C- http://bugs.python.org/issue1039
Re: [Python-Dev] Issues 9931 and 9055 - test_ttk_guionly and buildbot run as a service
On 11/12/2010 3:44 AM, Paul Moore wrote: Hi, My buildbot has been failing for some time because of these 2 issues, both related to the fact that tests are hanging when run as a service (and hence have no display to open GUI elements on). Both issues have patches, and as far as I am aware, the patches fix the issues reasonably well. What can I do to move these 2 issues forwards? As things stand, my buildbot is not providing a lot of value on the 3.x branch :-( http://bugs.python.org/issue9055 is marked as a 2.7 issue only, perhaps fixed by Tim Golden's committed patches. Should it be re-versioned for 3.1/2? There is no patch file attached, though perhaps the code in Yamamoto's message is meant as such (but for which version?). So the first thing you could do is clarify the current status and remaining issue on the tracker. http://bugs.python.org/issue9931 by Yamamoto is marked for all 3 versions. It seems to be a similar issue, though marked 'test' rather than 'ctypes'. It does have a patch by him apparently based on his previous comments. The issue has no responses and needs a patch review. So the first thing you could do is to provide one;-). If it looks great (no changes that you can think of) and works great, say so. Then it can move on to commit review stage. PS. Providing links like the above makes it easier for multiple people to take a look and respond. -- 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] bugs.python.org migration complete
On 11/12/2010 4:32 AM, "Martin v. Löwis" wrote: bugs.python.org is now on the new hardware. There have been some problems in the migration: the old hardware would start failing before the scheduled migration date, so the migration was done early, causing outage for some people who then the old address in their DNS caches. In addition, there was initially a misconfiguration preventing outgoing IP traffic, particularly preventing outgoing emails from being delivered. This is all fixed now; report any remaining issues to the metatracker. I got stymied by some of the late failures, but it has been working great, with quick response, since last night. Thanks for the upgrade. -- 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] buildbot master update
On 12 November 2010 16:15, Barry Warsaw wrote: > On Nov 12, 2010, at 10:29 AM, Martin v. Löwis wrote: > >>As you may have noticed: I updated the buildbot master to release 0.8.2. >>If you notice any problems, please post them here. > > Pretty! My buildbot seems fine. Yes, I like the new look. >>Slave operators can upgrade their installations at their own pace; >>buildbot is highly backwards compatible. As a recommendation, I suggest >>that slaves run at least at the version that is available in Debian >>stable (currently 0.7.8). > > Thanks Martin, for all you do to keep our infrastructure humming along > smoothly, including the recent Roundup migration. Thanks from me, too! Paul ___ 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] r86418 - in python/branches/release27-maint: Doc/library/difflib.rst Lib/difflib.py Lib/test/test_difflib.py Misc/NEWS
Hello, On Fri, 12 Nov 2010 00:22:19 +0100 (CET) terry.reedy wrote: > + > + .. versionadded:: 2.7 > + The *autojunk* parameter. Maybe I've missed something, but is there any reason to add a new parameter in a bugfix release? (apart from security issues) 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] Removal of Win32 ANSI API
> I'm not talking about Windows obviously. POSIX filenames are natively > bytes, so if you get a bytes filename from an external source, it makes > sense to reuse the bytes form. > > I think it would be a mistake to allow bytes filenames under POSIX but > not under Windows. It makes porting harder. Not really. People who want to write portable code should use Unicode filenames everywhere, not byte filenames. > >> - tar stores filenames... in the locale encoding (except for PAX format >> which >> uses utf-8) > > So bytes filenames are useful at least for tar. No, they are not. The tarfile module decodes all file names on its own, IIUC. 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] Removal of Win32 ANSI API
> Ok, good answer. In this case, I vote +1 to remove completly the ANSI version > from all Python modules. I think caution is still necessary. So I propose to deprecate byte filenames on Windows in 3.2, with removal in 3.3. People who think this is a terrible mistake and breaks there applications with no hope of a sensible solution can then still intervene. 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] buildbot master update
> Thanks Martin, for all you do to keep our infrastructure humming along > smoothly, including the recent Roundup migration. I just write the announcements :-) In this case. thanks should also extend to Izak Burger of Upfront Hosting who did most of the setup (I just did the DNS changes), and to bitdancer who investigated (together with Izak) the configuration problems of the new installation. 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] buildbot master update
On Fri, 12 Nov 2010 20:53:00 +0100 "Martin v. Löwis" wrote: > > Thanks Martin, for all you do to keep our infrastructure humming along > > smoothly, including the recent Roundup migration. > > I just write the announcements :-) In this case. thanks should also > extend to Izak Burger of Upfront Hosting who did most of the setup > (I just did the DNS changes), and to bitdancer who > investigated (together with Izak) the configuration problems of the new > installation. And for the record, bitdancer is R. David Murray :-) cheers 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
[Python-Dev] Closures / Python Scopes
A colleague of mine came across something anecdotal when working with lambdas, it is expressed by the following code snippet. In [1]: def a(): ...: for i in range(10): ...: def b(): ...: return i ...: yield b ...: ...: In [2]: funcs = list(a()) In [3]: print [f() for f in funcs] [9, 9, 9, 9, 9, 9, 9, 9, 9, 9] I understand that for loops in python do not have a scope, neither do if statements, and python is awesome for that. Is this something accidental? i.e. will python ever evolve into having scopes for if and for loops (and other blocks that are not functions)? the reason I ask is with the introduction of http://docs.python.org/py3k/reference/simple_stmts.html#nonlocal it seems like something that can happen. -- Hatem Nassrat ___ 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] r86418 - in python/branches/release27-maint: Doc/library/difflib.rst Lib/difflib.py Lib/test/test_difflib.py Misc/NEWS
On 11/12/2010 2:42 PM, Antoine Pitrou wrote: Hello, On Fri, 12 Nov 2010 00:22:19 +0100 (CET) terry.reedy wrote: + + .. versionadded:: 2.7 + The *autojunk* parameter. Maybe I've missed something, but is there any reason to add a new parameter in a bugfix release? (apart from security issues) This is a bugfix. We discussed this (with Tim's participation) here last July/August and pretty well agreed that this was the least obnoxious solution to a bad situation. -- 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] Closures / Python Scopes
On 11/12/2010 3:08 PM, Hatem Nassrat wrote: A colleague of mine came across something anecdotal when working with lambdas, it is expressed by the following code snippet. In [1]: def a(): ...: for i in range(10): ...: def b(): ...: return i ...: yield b ...: ...: In [2]: funcs = list(a()) In [3]: print [f() for f in funcs] [9, 9, 9, 9, 9, 9, 9, 9, 9, 9] I understand that for loops in python do not have a scope, neither do if statements, and python is awesome for that. Is this something accidental? i.e. will python ever evolve into having scopes for if and for loops (and other blocks that are not functions)? the reason I ask is with the introduction of http://docs.python.org/py3k/reference/simple_stmts.html#nonlocal it seems like something that can happen. Question/discussion issues like this belong on python-list or python-ideas list. -- 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] r86418 - in python/branches/release27-maint: Doc/library/difflib.rst Lib/difflib.py Lib/test/test_difflib.py Misc/NEWS
On 11/12/2010 3:32 PM, Terry Reedy wrote: On 11/12/2010 2:42 PM, Antoine Pitrou wrote: Hello, On Fri, 12 Nov 2010 00:22:19 +0100 (CET) terry.reedy wrote: + + .. versionadded:: 2.7 + The *autojunk* parameter. I just realized that this should say 2.7.1 so people know not to use it with the original 2.7. I will repeat it again in the SequenceMatcher section. Maybe I've missed something, but is there any reason to add a new parameter in a bugfix release? (apart from security issues) This is a bugfix. We discussed this (with Tim's participation) here last July/August and pretty well agreed that this was the least obnoxious solution to a bad situation. -- 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] Removal of Win32 ANSI API
On Sat, Nov 13, 2010 at 5:46 AM, "Martin v. Löwis" wrote: >> Ok, good answer. In this case, I vote +1 to remove completly the ANSI version >> from all Python modules. > > I think caution is still necessary. So I propose to deprecate byte > filenames on Windows in 3.2, with removal in 3.3. People who think this > is a terrible mistake and breaks there applications with no hope of a > sensible solution can then still intervene. I was going to suggest much the same thing. 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] r86418 - in python/branches/release27-maint: Doc/library/difflib.rst Lib/difflib.py Lib/test/test_difflib.py Misc/NEWS
On Sat, Nov 13, 2010 at 6:32 AM, Terry Reedy wrote: > On 11/12/2010 2:42 PM, Antoine Pitrou wrote: >> Maybe I've missed something, but is there any reason to add a new >> parameter in a bugfix release? >> (apart from security issues) > > This is a bugfix. We discussed this (with Tim's participation) here last > July/August and pretty well agreed that this was the least obnoxious > solution to a bad situation. Yep, as Terry said, the current behaviour is irredeemably broken in some situations, but switching it off completely would break other cases. Adding a new optional parameter that defaulted to the 2.7 behaviour was considered the least-bad option out of those available (do nothing, add parameter, change default behaviour, add new API). 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] r86441 - python/branches/py3k/Lib/test/test_nntplib.py
On 11/12/2010 7:28 PM, antoine.pitrou wrote: Author: antoine.pitrou Date: Sat Nov 13 01:28:53 2010 New Revision: 86441 Log: Switch from gmane to another provider for NNTP tests (as gmane isn't reliable enough). Also, use setUpClass in order to connect only once per test run. class NetworkedNNTP_SSLTests(NetworkedNNTPTestsMixin, unittest.TestCase): -NNTP_HOST = 'snews.gmane.org' -GROUP_NAME = 'gmane.comp.python.devel' -GROUP_PAT = 'gmane.comp.python.d*' gmane is most problematical on weekends. +NNTP_HOST = 'nntp.aioe.org' +GROUP_NAME = 'comp.lang.python' +GROUP_PAT = 'comp.lang.*' aioe went away for several months a couple of years ago or so. Let us hope it stays up for awhile now. The ssl connection currently does not work (expired certificate). Terry ___ 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] Breaking undocumented API
Steven D'Aprano wrote: By the way, did you intend to send this off-list? No, I didn't realise I hadn't sent it to the list. If you don't document them, I won't use them, because I won't know if it's one of these don't-ask-don't-tell pseudo-public functions or something private that's accidentally been given a non-underscore name. Greg Ewing wrote: Also it means that help() wouldn't show me documentation for the support functions, which is a bad thing if they really are intended for public use. I don't see why... if you import the module, and call help(module), they will show up as normal. If the module has an __all__ list, then help(module) will only show functions included in that list. So your pseudo-public functions would not show up in it. Without some other reason to suspect their existence, I would probably never find them. -- 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] Breaking undocumented API
On Fri, Nov 12, 2010 at 1:49 AM, Hrvoje Niksic wrote: > On 11/11/2010 11:24 PM, Greg Ewing wrote: >> >> Nick Coghlan wrote: >> >>> My personal opinion is that we should be trying to get the standard >>> library to the point where __all__ definitions are unnecessary - if a >>> name isn't in __all__, it should start with an underscore (and if that >>> is true, then the __all__ definition becomes effectively redundant). >> >> What about names imported from other modules that are used by >> the module, but not intended for re-export? How would you >> prevent them from turning up in help() etc. without using >> __all__? > > import foo as _foo > > I believe I am not the only one who finds that practice ugly, Agreed. > but I find it > just as ugly to underscore-ize every non-public helper function. __all__ is > there for a reason, let's use it. Maybe help() could automatically ignore > stuff not in __all__, or display it but warn the user of non-public > identifiers? No, I like all non-public functions, constants, classes and variables (but excluding imported modules) to start with _. You'd still need __all__ to make "import *" do the right thing, but the reader of the source code should not have to look up every name in __all__ to find whether it is supposed to be public or private. Plus, the same convention should carry over to methods and other class attributes, where you don't have __all__. If help() is broken we should fix it. (I'm not very happy with it myself anyway, I rarely use it.) Note that __all__ was originally invented to give "from package import *" a well-defined meaning when the package included submodules that might not have been loaded yet. Using it for other export control (while a good idea) could be considered "newfangled". :-) -- --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
