[issue469773] Write 'Using Python on Platform X' documents
Changes by Fred L. Drake, Jr.: -- assignee: fdrake -> Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue469773> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue870479] Scripts need platform-dependent handling
Fred L. Drake, Jr. added the comment: Removing the assignment to me, since I'm not going to resolve the fundamental disagreements about what "the right thing" is. Someone else can argue with the wrong-headed. -- assignee: fdrake -> Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue870479> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1209562] add single html files
Fred L. Drake, Jr. added the comment: Might be nice, but it's obvious I've not gotten to this, so removing myself from the issue. -- assignee: fdrake -> _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1209562> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1126] file.fileno and file.isatty() should be implementable by any file like object
Fred L. Drake, Jr. added the comment: The documentation does not say what's implied by msg55724; they methods can (and arguably should) be implmented by types for which they apply (for which there is a corresponding file descriptor, for example). There is an API issue here as well: what about a wrapper type that is sometimes associated with a real file, and sometimes not? I suppose in that case the factory (constructor) needs to detect the situation and return an instance of an appropriate type. The documentation is clear, so far as it goes, but is arguably incomplete. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1126> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1172] Documentation for done attribute of FieldStorage class
Fred L. Drake, Jr. added the comment: Looks good to me too. This should be committed. -- assignee: fdrake -> jafo resolution: -> accepted versions: +Python 2.5, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1172> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1053] bogus attributes reported in asyncore doc
Fred L. Drake, Jr. added the comment: Fixed for the 2.5.2 (revision 58328) and 2.6 (revision 58327) releases. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1053> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1317] smtplib.SMTP docs
New submission from Fred L. Drake, Jr.: The docstring for the smtplib.SMTP class includes descriptions of some instance attributes that are not covered by the documentation: does_esmtp ehlo_resp esmtp_features helo_resp If these are intended as part of the public interface, they should be documented in the .tex/.rst documentation, otherwise their descriptions should be in a comment instead of a docstring. (helo_resp is mentioned in Misc/HISTORY, if that actually means anything.) -- components: Documentation messages: 56688 nosy: fdrake severity: normal status: open title: smtplib.SMTP docs type: rfe versions: Python 2.5, Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1317> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Changes by Fred L. Drake, Jr. : -- nosy: -fdrake ___ Python tracker <http://bugs.python.org/issue670664> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11379] Remove "lightweight" from minidom description
Fred L. Drake, Jr. added the comment: Removing "Lightweight" and changing the first paragraph to (something like) :mod:`xml.dom.minidom` is an implementation of the Document Object Model interface. The API is slightly simpler than the full W3C DOM, but the implementation has a significantly higher memory footprint than :mod:`xml.dom.etree`. would be entirely reasonable. (I don't think it's wrong to discuss relative memory footprints in comparison to other modules in the standard library.) -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue11379> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12226] use secured channel for uploading packages to pypi
Fred L. Drake, Jr. added the comment: On Wed, Jun 1, 2011 at 11:14 AM, anatoly techtonik wrote: > Adding catalog-sig to CC. I can guarantee this for Windows. I'll be > near Linux box tomorrow and will try upload to PyPI from there. It > still will be more authoritative if more than one person can test > upload to PyPI with this patch on different systems. The interesting case will be for a build that doesn't include SSL support. -Fred -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue12226> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12226] use secured channel for uploading packages to pypi
Fred L. Drake, Jr. added the comment: On Mon, Jun 6, 2011 at 11:50 AM, Éric Araujo wrote: > If you make an HTTPS connection without checking the certificate, what > security does it add? I'm in favor of cert checking, myself. -- ___ Python tracker <http://bugs.python.org/issue12226> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12394] packaging: generate scripts from callable (dotted paths)
Fred L. Drake, Jr. added the comment: People working on this should probably also look at how zc.buildout's zc.recipe.egg handles script generation. It's similar to setuptools in that "console_script" entry points are used, but it binds in the desired Python executable as well. (If you ran the build with an unversioned Python executable name, that's what you get, but if you use a versioned path, it's retained.) -- ___ Python tracker <http://bugs.python.org/issue12394> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12409] Moving "Documenting Python" to Devguide
Fred L. Drake, Jr. added the comment: -1 > Hi! We have the devguide now, and it should be the place where to look > for references and docs about contributing to Python, that means also > for the documentation. For information specific to the Python documentation itself, but not relevant to users documenting their own projects, yes. > In the official Python doc we have a section "Documenting Python" > (http://docs.python.org/py3k/documenting/index.html) and I think it > should be merged into the devguide - what's your opinion on that? The scope of this document is much larger than Python's documentation, but extends to all projects written in Python that use Sphinx as their documentation tool. With that, it makes sense to keep it as part of the documentation for users of Python. -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue12409> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10149] Data truncation in expat parser
Fred L. Drake, Jr. added the comment: Chunking of the data is expected with Expat. There are no promises about *where* chunks are broken; the underlying behavior will break at line endings, but is not limited to that. Setting buffer_text informs the Python wrapper that it's allowed to combine the chunks reported by the Expat library; this was made optional since it could affect working applications (changing the default with the move to Python 3 may have been acceptable, though). -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue10149> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9584] Allow curly braces in fnmatch
Fred L. Drake, Jr. added the comment:
It's worth noting that the sh-like shells are far more widely used than the
csh-like shells, so csh-like behavior may surprise more people.
>From the sh-like shell perspective, the {...,...} syntax just isn't part of
>the globbing handling.
--
nosy: +fdrake
___
Python tracker
<http://bugs.python.org/issue9584>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1055864] HTMLParser not compliant to XHTML spec
Fred L. Drake, Jr. added the comment: Indeed it is. Closing, won't fix. HTMLParser tries to deal with XHTML constructs only so much as HTML ends up with that stuff, not because it's trying to handle everything. (The claimed example appears not to have been attached, anyway.) -- resolution: -> wont fix status: open -> closed ___ Python tracker <http://bugs.python.org/issue1055864> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2830] Copy cgi.escape() to html
Fred L. Drake, Jr. added the comment: Encoding the forward slash should not cause problems, but the quote “forward slash is included as it helps end an HTML entity” is confused; there's no need or additional value in escaping the forward slash. -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue2830> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7005] ConfigParser does not handle options without values
Fred L. Drake, Jr. added the comment: Re-opening for investigation. (The previous message really should have been a new issue.) -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue7005> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7005] ConfigParser does not handle options without values
Changes by Fred L. Drake, Jr. : -- nosy: +lukasz.langa ___ Python tracker <http://bugs.python.org/issue7005> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7005] ConfigParser does not handle options without values
Fred L. Drake, Jr. added the comment: I've attached a diagnostic script that I ran with Python 2.4..3.2 (current py3k HEAD); there are two output variants: "old style": [section] option = None "new style": [section] option This is the output I get when running this script for each of those Python versions: 2.4.6 RawConfigParser: old-style output 2.4.6 SafeConfigParser: raised TypeError on set 2.4.6 ConfigParser: old-style output 2.5.5 RawConfigParser: old-style output 2.5.5 SafeConfigParser: raised TypeError on set 2.5.5 ConfigParser: old-style output 2.6.5 RawConfigParser: old-style output 2.6.5 SafeConfigParser: raised TypeError on set 2.6.5 ConfigParser: old-style output 2.7 RawConfigParser: new-style output 2.7 SafeConfigParser: raised TypeError on set 2.7 ConfigParser: new-style output 3.1.1 RawConfigParser: old-style output 3.1.1 SafeConfigParser: raised TypeError on set 3.1.1 ConfigParser: old-style output 3.2a1+ RawConfigParser: new-style output 3.2a1+ SafeConfigParser: raised TypeError on set 3.2a1+ ConfigParser: new-style output Essentially: For the RawConfigParser and ConfigParser classes, the output changes in 2.7 and 3.2, and in a way that should be considered incorrect because it conflicts with the allow_no_values setting. This is a bug and should be fixed in both 2.7 and 3.2. The TypeError-on-set is consistently raised only for SafeConfigParser, and should remain unchanged. (Why this was handled differently for SafeConfigParser I don't recall offhand.) -- Added file: http://bugs.python.org/file18717/cpsample.py ___ Python tracker <http://bugs.python.org/issue7005> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7005] ConfigParser does not handle options without values
Fred L. Drake, Jr. added the comment: Attached fix & test for Python 2; adjusting to Python 3 is trivial. The test could be added to 2.6 as well to protect against regressions there, though that's unlikely to be a significant issue. -- Added file: http://bugs.python.org/file18718/issue-7005.patch ___ Python tracker <http://bugs.python.org/issue7005> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7005] ConfigParser does not handle options without values
Fred L. Drake, Jr. added the comment: Commited as r84443 (release27-maint), r8 (py3k) -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue7005> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9421] configparser.ConfigParser's getint, getboolean and getfloat don't accept `vars`
Fred L. Drake, Jr. added the comment: My question in IRC wasn't intended to mean "why are we passing settings to the constructor" so my much as "why are these configuration settings"; sorry I wasn't clear. Have we encountered actual use cases that are not covered by the existing code? I don't recall ever seeing a request for more flexibility in that regard. -- ___ Python tracker <http://bugs.python.org/issue9421> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9421] configparser.ConfigParser's getint, getboolean and getfloat don't accept `vars`
Fred L. Drake, Jr. added the comment: Regardless, my concerns about including delimiters and comment_prefixes as settings is irrelevant to this issue. The changes to them probably shouldn't have been part of this issue to begin with, but I'll try not to lose sleep over it at this point. -- ___ Python tracker <http://bugs.python.org/issue9421> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9421] configparser.ConfigParser's getint, getboolean and getfloat don't accept `vars`
Fred L. Drake, Jr. added the comment: The patch has been commited largely as-is (r84486). I'm not happy with the documentation yet: - Markup like this: .. method:: ConfigParser.getint(section, option, raw=False, [vars, default]) doesn't sit well with me. I'm going to dig around current practice a bit and discuss with Georg sometime over the next few days, and see how best to adjust that. - Inclusion of references to internal names in the API docs, like this in the signatures: comment_prefixes=_COMPATIBLE is just bad form. Again, we need a better way. I suspect there is little if any considered precedent, so we'll come up with something. Neither of these are blockers; we can adjust this independently of the code and doocumentation content. (It's not part of the feature.) Leaving this issue open for the completion of these changes. -- resolution: -> accepted ___ Python tracker <http://bugs.python.org/issue9421> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue976869] Stripping script extensions with distutils
Fred L. Drake, Jr. added the comment: At this point, I'm more in favor of adopting something closer to the setuptools scripts based on "console_scripts" entry points, and dropping old-style scripts entirely (most *because* of the issues I mentioned at the start). -- ___ Python tracker <http://bugs.python.org/issue976869> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue870479] Scripts need platform-dependent handling
Fred L. Drake, Jr. added the comment: As noted in issue 976869, I'm very much in the camp of entry-point based generated scripts, which should clearly use the right line endings for the host platform. Hacking around with the file copy just doesn't make sense moving forward. -- ___ Python tracker <http://bugs.python.org/issue870479> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10038] Returntype of json.loads() on strings
Fred L. Drake, Jr. added the comment: This is related to this issue from simplejson: http://code.google.com/p/simplejson/issues/detail?id=28 This problem is why I still use simplejson 1.x; moving forward to simplejson 2.x or Python's json is unlikely. -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue10038> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10038] Returntype of json.loads() on strings
Fred L. Drake, Jr. added the comment: As I understand it, the decision to return str instead of unicode values for the "simplejson" module was simply inherited by the standard library. As such, it still needs to be evaluated in the context of the standard library, because of the incompatibility it introduces. I still maintain that it's a bug, and should be treated as such. -- ___ Python tracker <http://bugs.python.org/issue10038> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10045] poor cStringIO.StringO seek performance
Changes by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue10045> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10045] poor cStringIO.StringO seek performance
Fred L. Drake, Jr. added the comment: Causing perfectly good Python 2 applications to degrade in performance is bad, even if something else is available. This should be fixed as a regression. -- ___ Python tracker <http://bugs.python.org/issue10045> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10045] poor cStringIO.StringO seek performance
Fred L. Drake, Jr. added the comment: Ok, reading more carefully, it's not a regression. But it's certainly a bug, and should be fixed. -- ___ Python tracker <http://bugs.python.org/issue10045> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10045] poor cStringIO.StringO seek performance
Fred L. Drake, Jr. added the comment: Assigning to myself for review. -- assignee: -> fdrake keywords: +needs review ___ Python tracker <http://bugs.python.org/issue10045> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10045] poor cStringIO.StringO seek performance
Fred L. Drake, Jr. added the comment: Committed with minor changes in r85366 (release27-maint branch). -- keywords: -needs review resolution: -> accepted status: open -> closed ___ Python tracker <http://bugs.python.org/issue10045> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10108] ExpatError not property wrapped
Changes by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue10108> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10038] Returntype of json.loads() on strings
Fred L. Drake, Jr. added the comment: I'll note that it seems relevant that this package is not considered "externally maintained" by the terms of PEP 360: http://www.python.org/dev/peps/pep-0360/ Given the level of attention this has received from the originator of the code, we should not hesitate to commit technically acceptable changes to the Python repository, -- title: json.loads() on str should return unicode, not str -> Returntype of json.loads() on strings ___ Python tracker <http://bugs.python.org/issue10038> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10038] json.loads() on str should return unicode, not str
Changes by Fred L. Drake, Jr. : -- title: Returntype of json.loads() on strings -> json.loads() on str should return unicode, not str ___ Python tracker <http://bugs.python.org/issue10038> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10038] json.loads() on str should return unicode, not str
Fred L. Drake, Jr. added the comment: Alternately, the Python implementation may be thought of as definitive and the optimizations are broken. -- ___ Python tracker <http://bugs.python.org/issue10038> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10038] json.loads() on str should return unicode, not str
Fred L. Drake, Jr. added the comment: The incomplete testing and C/Python implementation mismatch are covered by issue 5723 and issue 9233. -- ___ Python tracker <http://bugs.python.org/issue10038> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10299] Add index with links section for built-in functions
Changes by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue10299> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5412] extend configparser to support mapping access(__*item__)
Fred L. Drake, Jr. added the comment:
Code
- The __name__-aversion in the mapping interface is a little
heavy-handed, but given the implementation of __name__ elsewhere, I
think this can be revisited separately if anyone cares enough.
In particular, it should be allowed to give an __name__ value
explicitly and have it exposed:
>>> import configparser
>>> import io
>>> cp = configparser.RawConfigParser()
>>> cp.read_file(io.StringIO('[sect]\n__name__ = FooBar\n'))
>>> cp.get('sect', '__name__')
'FooBar'
>>> cp['sect']['__name__']
Traceback (most recent call last):
File "", line 1, in
File ".../py3k/Lib/configparser.py", line 1132, in __getitem__
raise ValueError(self._noname)
ValueError: __name__ special key access and modification not supported
through the mapping interface.
In this example, the __name__ key isn't special, it's just a key.
Documentation
=
- I dislike the 'fallback'/'default' terminology problem; everywhere
else, the fallback is called 'default'. This really points to
configparser (ne ConfigParser) not having been fully thought out
before it was released as part of Python. There's probably nothing
to be done about it at this point.
Has anyone attempted to determine how widely used the "defaults"
(mis-)feature is? I've not seen a good user for it as implemented
outside the original application ConfigParser was written for
(though others probably exist that have a similar need).
- There's no value in saying
`None` can be provided as a `fallback` value.
(regardless of the terminology). None is a value like any other, and
the docs already indicate it is used if provided. If anything need be
said, identify the exception raised if the default isn't provided and
no value is present.
Identifying None as a possible value isn't needed or done in any of
the mapping descriptions, so let's not add it here, even for the
methods that don't correlate to mapping methods.
- I dislike the documentation style where we indicate arguments are
keyword-only using a bare * in the signature, and then repeat that in
prose (this is not the only place this happens). It's redundant
(more work to maintain) and more verbose than helpful.
I still need to give the new docs a thorough read.
--
___
Python tracker
<http://bugs.python.org/issue5412>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10358] Doc styles for print should only use dark colors
New submission from Fred L. Drake, Jr. : The HTML version of the documentation should include style settings for printing that use fairly dark colors, so that printed copies of pages are more readable. Using a printer that reduces colors to grays causes the light colors in code examples (or inlined references to classes and the like) to nearly drop out, making the result very painful to read. -- assignee: d...@python components: Documentation keywords: easy messages: 120741 nosy: d...@python, fdrake priority: normal severity: normal stage: needs patch status: open title: Doc styles for print should only use dark colors type: feature request ___ Python tracker <http://bugs.python.org/issue10358> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10386] token module should define __all__
Fred L. Drake, Jr. added the comment: Normally, I'd recommend leaving the "main" name alone, but in the case of modules that use it as an tool for module maintenance (symbol, token), I don't think it matters either way. Ok to commit. -- assignee: -> belopolsky nosy: +fdrake resolution: -> accepted ___ Python tracker <http://bugs.python.org/issue10386> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10373] Setup Script example incorrect
Fred L. Drake, Jr. added the comment: > perhaps the web page should be checked for an incorrect link. The link from the Python documentation to the Python bug tracker is fine. If you were using distutils directly, it would be an issue for the Python tracker. You're not. setuptools is a separate project; you should refer to it's documentation and it's tracker. -- nosy: +fdrake resolution: -> rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue10373> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10403] Use "member" consistently
New submission from Fred L. Drake, Jr. : Some portions of the documentation are using the term "member" to mean "data attribute". This appears to be an aberration at this time, but occurrences should be identified and corrected, and "Documenting Python" updated to note correct usage. Example use: http://docs.python.org/dev/py3k/library/xmlrpc.client.html#fault-objects http://docs.python.org/dev/py3k/library/urllib.request.html#basehandler-objects (paragraph starting "The following members and methods should") "Members and methods" should just be "attributes". -- assignee: d...@python components: Documentation messages: 121110 nosy: d...@python, fdrake priority: normal severity: normal status: open title: Use "member" consistently ___ Python tracker <http://bugs.python.org/issue10403> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10403] Use "member" consistently
Changes by Fred L. Drake, Jr. : -- keywords: +easy ___ Python tracker <http://bugs.python.org/issue10403> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11372] Remove xrange from argparse docs
Fred L. Drake, Jr. added the comment: Committed for Python 3.3.0: r88717 Committed for Python 3.2.1: r88718 -- assignee: docs@python -> fdrake nosy: +fdrake resolution: -> accepted stage: -> committed/rejected status: open -> closed versions: +Python 3.2 ___ Python tracker <http://bugs.python.org/issue11372> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9101] reference json format in file formats chapter
Fred L. Drake, Jr. added the comment: And what are these people looking for? "json"? If so, there's already an entry in the module index. That seems sufficient. -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue9101> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Changes by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12043] Update shutil documentation
Changes by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue12043> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9173] logger statement not guarded in shutil._make_tarball
Fred L. Drake, Jr. added the comment: > By the way, the logger argument is not documented in shutil.rst. This documentation issue is distinct from this; this bug affects applications that *don't* use the logger argument. -- ___ Python tracker <http://bugs.python.org/issue9173> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10434] Document the rules for "public names"
Changes by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue10434> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10499] Modular interpolation in configparser
Fred L. Drake, Jr. added the comment: Review posted. -- ___ Python tracker <http://bugs.python.org/issue10499> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10589] I/O ABC docs should specify which methods have implementations
Changes by Fred L. Drake, Jr. : -- nosy: +d...@python, fdrake ___ Python tracker <http://bugs.python.org/issue10589> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7904] urlparse.urlsplit mishandles novel schemes
Fred L. Drake, Jr. added the comment: Though msg104261 suggests this change be documented in NEWS.txt, it doesn't appear to have made it. Sure enough, we just found application code that this broke. -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue7904> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10664] xml.sax.expatreader should support namespace prefixes
New submission from Fred L. Drake, Jr. : The xml.sax.expatreader module pre-dates prefix reporting from Expat, and should be modified to support the feature_namespace_prefixes feature instead of complaining that Expat doesn't support prefixes. -- assignee: fdrake components: XML messages: 123699 nosy: fdrake priority: normal severity: normal stage: needs patch status: open title: xml.sax.expatreader should support namespace prefixes type: feature request versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue10664> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10697] host and port attributes not documented well in function urllib.parse.urlparse and urlsplit
Fred L. Drake, Jr. added the comment: These attributes were added in Python 2.5. Documentation improvements should be backported to 2.7 and 3.1. -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue10697> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10697] host and port attributes not documented well in function urllib.parse.urlparse and urlsplit
Changes by Fred L. Drake, Jr. : -- versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue10697> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10932] distutils.core.setup - data_files misbehaviour ?
Fred L. Drake, Jr. added the comment:
On Wed, Jan 19, 2011 at 12:42 PM, Éric Araujo wrote:
> I understand this line to mean that only the basename of the file will be used
> in the target directory, IOW that ('config', ['cfg/data.cfg']) will create a
> file in config/data.cfg, not config/cfg/data.cfg.
> I’m not 100% sure about my reading though, this line is confusing.
This is my reading as well.
--
___
Python tracker
<http://bugs.python.org/issue10932>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10936] Simple CSS fix for left margin at docs.python.org
Fred L. Drake, Jr. added the comment: As Ezio noted, the coming versions of the Python 3 documentation provide a way to collapse the sidebar completely. Perhaps a min-width should be specified, but I'm not convinced that's a good idea. The sidebar problem is fairly significant, and the collapsing sidebar alone isn't sufficient. The sidebar is useful since it's the only overall navigation structure (as opposed to the direct links embedded in the content), but there's no real need to ensure it gets "enough" width. I'd rather see a simple adjustment as recommended by Christopher Dunn. I appreciate Ezio's in making the sidebar collapsible, but I think that's just the first step. The sidebar is certainly the most contentious element of the new design, and the most difficult to get right. -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue10936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10936] Simple CSS fix for left margin at docs.python.org
Fred L. Drake, Jr. added the comment: On Thu, Jan 20, 2011 at 11:18 PM, Ezio Melotti wrote: > If it gets too narrow it would start getting unusable and the text will start > overflowing. If someone is zooming that much, it's because they really need the size of the text more than anything (trust me; I've tried to work while my eyes were dilated; size is *everything* at that point). The worst thing to do in such situations is to get in the way of the browser's normal behavior. -- ___ Python tracker <http://bugs.python.org/issue10936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10936] Simple CSS fix for left margin at docs.python.org
Fred L. Drake, Jr. added the comment: On Fri, Jan 21, 2011 at 2:58 AM, Christopher Dunn wrote: > For narrow-width screens, there really shouldn't be a sidebar. Maybe a > dynamic element would be better. Right. I'd be in favor of removing the sidebar and having a pop-out ToC navigator of some sort. Most of the time, most of us are looking at the content, not at how to navigate the content. Spending so much screen real-estate on navigation is painful. Large, hi-res screens just aren't *that* cheap yet. -- ___ Python tracker <http://bugs.python.org/issue10936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11027] Allow spaces around section header in ConfigParser
Fred L. Drake, Jr. added the comment: I doubt anyone is looking for section names with leading or trailing whitespace. One approach to dealing with this is to provide and sectionxform similar to optionxform. If we're wrong and someone really is expecting leading or trailing whitespace, they can set that (to str) to cancel out the change in behavior. While I'd be surprised if anyone relies on this, it is a feature change, no matter how it's implemented, so must wait for 3.3. -- ___ Python tracker <http://bugs.python.org/issue11027> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2882] Create the html package
Changes by Fred L. Drake, Jr. <[EMAIL PROTECTED]>: -- assignee: -> fdrake nosy: +fdrake __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2882> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2882] Create the html package
Fred L. Drake, Jr. <[EMAIL PROTECTED]> added the comment: Completed in revisions 63430, 63432, 63434 (Python 2.6), and 63431, 63435, 63439 (Python 3.0). -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2882> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2775] Implement PEP 3108
Fred L. Drake, Jr. <[EMAIL PROTECTED]> added the comment: The html package has been created (issue 2882). -- nosy: +fdrake __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2775> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2882] Create the html package
Fred L. Drake, Jr. <[EMAIL PROTECTED]> added the comment: Python 2.6 changes reverted in revision 63481. Does anyone really want to pickle HTML parser state, or references to the helper functions in the htmlentitydefs module? I suspect head examinations may be in order. :-( -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2882> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2775] Implement PEP 3108
Fred L. Drake, Jr. <[EMAIL PROTECTED]> added the comment: On May 21, 2008, at 10:16 AM, Mark Dickinson wrote: > I'm working on issue 2873 (remove htmllib dependency from pydoc). Thanks, Mark! I was dreading the thought of looking at that. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2775> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2888] pprint produces different output in 2.6 and 3.0
Fred L. Drake, Jr. <[EMAIL PROTECTED]> added the comment: The version seen in py3k is the intended formatting; I don't remember anything about a change, but given the time I've not had in following commit messages and discussions, I could easily have missed something. I'm strongly in favor of the output from the Python 3.0 version; the 2.6 version is silly, even if you're not already laughing at the indent parameter. (When I first wrote pprint, I was working with huge nested tuples, for which I found the indentation control useful. Haven't used it since, though I suspect that's the sort of thing that makes others try it out.) ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2888> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2888] pprint produces different output in 2.6 and 3.0
Fred L. Drake, Jr. <[EMAIL PROTECTED]> added the comment: I will note that Python 2.5 matches Python 3.0 in this regard. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2888> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2888] pprint produces different output in 2.6 and 3.0
Fred L. Drake, Jr. <[EMAIL PROTECTED]> added the comment: The patch doesn't include a new test to cover this case. That needs to be written and applied to both trunk and py3k. -- versions: +Python 2.6 -Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2888> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2888] pprint produces different output in 2.6 and 3.0
Fred L. Drake, Jr. <[EMAIL PROTECTED]> added the comment: The attached test_pprint.diff adds a test for this problem. This test passes for the py3k and release25-maint branches and fails for the trunk. Applying Manuel Kaufmann's pprint.diff patch to the trunk causes it to pass as well. I'll leave it for someone else to figure out the right svnmerge dance to keep the trunk and py3k properly in sync. The test should be applied to the py3k, release25-maint, and trunk branches, at any rate. Added file: http://bugs.python.org/file10460/test_pprint.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2888> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2873] Remove htmllib use in the stdlib
Fred L. Drake, Jr. <[EMAIL PROTECTED]> added the comment: I'd be happy to see both htmllib and pydoc be removed; documentation tools do quite well as separate applications. Not as convenient for interactive use, but easy enough to hook in via PYTHONSTARTUP. -- nosy: +fdrake ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2873> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3829] Tuple comparison masking exception
New submission from Fred L. Drake, Jr. <[EMAIL PROTECTED]>: There's a strange condition where cmp() of tuples of unorderable values returns -1 even though using the unorderable values raises an exception. If I have these two unorderable values, cmp() raises an expected exception: >>> s0 = frozenset(['testing 0']) >>> s1 = frozenset(['testing 1']) >>> cmp(s0, s1) Traceback (most recent call last): File "", line 1, in ? TypeError: cannot compare sets using cmp() Comparing tuples of the values returns -1: >>> cmp((s0,), (s1,)) -1 Py3k does raise a TypeError, but the message is indecipherable: >>> cmp((s0,), (s1,)) Traceback (most recent call last): File "", line 1, in TypeError: unorderable types: 'tuple' != 'tuple' (The Py3k message for the set comparison is the same as for Python 2.) I believe that this is an error; the exception from the underlying item comparison should be propagated. -- components: Interpreter Core messages: 72981 nosy: fdrake severity: normal status: open title: Tuple comparison masking exception type: behavior versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3829> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2218] Enhanced hotshot profiler with high-resolution timer
Fred L. Drake, Jr. <[EMAIL PROTECTED]> added the comment: May I ask what the reasoning is for further developing hotshot as part of the core? My understanding, based on discussions on python-dev, is that hotshot is being deprecated in favor of cProfile. If hotshot still provides functionality that's interesting (and it may), perhaps it makes sense to maintain and improve it in a separate distribution. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2218> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6877] enable compilation of readline module on Mac OS X 10.5 and 10.6
Changes by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue6877> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7005] ConfigParser does not handle options without values
Fred L. Drake, Jr. added the comment: Assigning to myself for handling. Bumping to Python 2.7 / 3.2 since support for this syntax variation is a new feature. -- assignee: -> fdrake versions: +Python 2.7, Python 3.2 -Python 2.6 ___ Python tracker <http://bugs.python.org/issue7005> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7005] ConfigParser does not handle options without values
Fred L. Drake, Jr. added the comment: Patch and documentation merged to the py3k branch (r78233). Work on this is complete. -- resolution: -> accepted stage: -> committed/rejected status: open -> closed type: -> feature request ___ Python tracker <http://bugs.python.org/issue7005> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7540] urllib2 request does not update content length after new add_data
Fred L. Drake, Jr. added the comment: This change breaks existing uses of Python 2.6.4. The mechanize library frequently re-initializes the data in the request without re-using the request. Applications (including tests) that use mechanize now break with this TypeError. The proper response to this issue for Python 2.6 is to make no code changes (though a documentation enhancement may be in order). This change should be reverted from all branches. Python 2.6.5 should be blocked until this is done. -- nosy: +fdrake status: closed -> open ___ Python tracker <http://bugs.python.org/issue7540> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7540] urllib2 request does not update content length after new add_data
Fred L. Drake, Jr. added the comment: To clarify: Multiple calls to add_data on a urllib2 request, when the request isn't being reused, are in no way invalidated by the problem initially reported. -- ___ Python tracker <http://bugs.python.org/issue7540> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7540] urllib2 request does not update content length after new add_data
Fred L. Drake, Jr. added the comment: I'd like to hear at least one other say-so (which can be yours if you agree this is the right thing), so there's more recognized consensus on the matter. We also need an explicit go-ahead from Barry as the release manager. At this point, the community sees only my assertion that this is a regression from 2.6.4. I'd be fine with a documentation improvement going in as well (as a separate commit), but that's not a requirement to deal with the release block. Before the release, it would require a separate go-ahead from the release manager. -- ___ Python tracker <http://bugs.python.org/issue7540> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7540] urllib2 request does not update content length after new add_data
Fred L. Drake, Jr. added the comment: Reopening; per discussion on IRC, the change needs to be reverted on the other three branches to which it was applied. If code changes are needed to make unsupported usage fail early, they need to be considered carefully and only applied as a new feature. -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue7540> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7540] urllib2 request does not update content length after new add_data
Fred L. Drake, Jr. added the comment: The reverts in SVN look good to me; re-closing this issue as no further action is required. If there's a proposal for specific changes to urllib2 to improve diagnostics in unsupported cases, that should be detailed in a separate issue. Marking this issue "invalid" since the original reported symptom was determined to be caused by an unsupported use (re-use of the request). -- resolution: accepted -> invalid status: open -> closed ___ Python tracker <http://bugs.python.org/issue7540> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8638] Remove suggestion for name mangling from the tutorial
Fred L. Drake, Jr. added the comment: On Fri, May 7, 2010 at 6:35 PM, Terry J. Reedy wrote: > This is such an advanced and rarely used feature that it hardly seems > appropriate for the tutorial. The problem with just leaving it out is that learners stumbling over them in existing code (likely by trying to use something that looks like it should be there and getting an AttributeError) won't have a chance of knowing what the problem might be. I'd be fine seeing new uses discouraged, especially for new learners, but I think it's important that they be given a heads-up as well. -Fred -- nosy: +fdrake ___ Python tracker <http://bugs.python.org/issue8638> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue932563] logging: need a way to discard Logger objects
Fred L. Drake, Jr. added the comment: Ideally, it would be best if loggers didn't live forever behind the scenes if they have no non-default configuration, but documenting their long-lived nature and the recommended alternate ways to deal with getting additional context information into the results. Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue932563> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue932563] logging: need a way to discard Logger objects
Fred L. Drake, Jr. added the comment: Please be sure to post a link to the thread here, as not everyone here reads comp.lang.python. Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue932563> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue487738] weaklist
Fred L. Drake, Jr. added the comment: Facundo: Agreed as well; since the use case isn't strong, let's avoid adding this. -- resolution: -> rejected status: open -> closed Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue487738> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue803422] sgmllib doesn't support hex or Unicode character references
Fred L. Drake, Jr. <[EMAIL PROTECTED]> added the comment: SGML TC 2 can be found here: http://www1.y12.doe.gov/capabilities/sgml/wg8/document/1955.htm See the section K.4.1 for hexidecimal character references. Since this is really an update to the SGML standard, and not part of the original, any support for this should be an optional feature. It's really only interesting on the web, where standards compliance is... a little on the lax side. It would be reasonable to enable this by default from htmllib (if not already supported in htmllib; I don't remember). I'm fairly sure hex character references are already supported in HTMLParser. -- nosy: +fdrake Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue803422> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup loops with better bytecode
Changes by Fred L. Drake, Jr. <[EMAIL PROTECTED]>: __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2459> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup loops with better bytecode
Changes by Fred L. Drake, Jr. <[EMAIL PROTECTED]>: __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2459> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2174] xml.sax.xmlreader does not support the InputSource protocol
Fred L. Drake, Jr. <[EMAIL PROTECTED]> added the comment: It's certainly arguable that the current behavior is a bug, though I suspect it shouldn't be considered major since I've not seen any prior complaints about this. It should be easy to fix the bug you describe by taking the character stream and encoding it before feeding it to the XML parser; Expat can certainly be forced to take a known encoding, ignoring what's in the XML declaration. On the other hand, it's not at all clear that changing this is worthwhile. This API borrows quite literally from the Java SAX APIs; perhaps this separation of the character stream from the byte stream makes sense for some of the Java XML parsers, but I don't know that there are any Python parsers that benefit from that separation. -- components: -Library (Lib), Unicode priority: normal -> low __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2174> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2385] run_setup can fail if the setup script uses __file__
Fred L. Drake, Jr. <[EMAIL PROTECTED]> added the comment: I don't think these are the right thing to do. 1. Your run_setup() changes add a os.chdir(), but then uses the path to the script as passed in; this assumes that the provided path is absolute, which is not a good assumption. That is not currently required. The effect is that a path that works currently may not work after the change. A relative path will not be usable to locate support files in this case, since it no longer refers to the directory is used to. Also, the way you restore the current directory doesn't work; os.curdir isn't what you think it is. This isn't covered in the test, either. 2. Apparently there are setup.py scripts that test __name__ (this surprised me, but Google Code Search says there are many: http://www.google.com/codesearch?q=file%3Asetup.py+%22__main__%22). This change would affect those that are currently seeing "__builtin__" (picked up from the built-in namespace). Arguably, it's reasonable to expect run_setup() to restore the current directory if a setup.py script does change it, but it's not clear that the change in behavior wouldn't cause problems for existing scripts. I've adjusted the patch so that the __file__ is supported, but the other behaviors are omitted. This has been commited in revision 62142 on the trunk. -- assignee: -> fdrake nosy: +fdrake priority: -> low __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2385> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2385] run_setup can fail if the setup script uses __file__
Fred L. Drake, Jr. <[EMAIL PROTECTED]> added the comment: Here's a patch that restores the current directory after running the script. The distutils-sig should probably determine if that's the right thing to do. Includes test. Added file: http://bugs.python.org/file9936/run_script-restores-cwd.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2385> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2385] run_setup can fail if the setup script uses __file__
Fred L. Drake, Jr. <[EMAIL PROTECTED]> added the comment: Of course, my previous commit did what I said it should not in #1 above: it changed the current directory to the directory in which the setup.py script lived (which made __file__ wrong). Fixed in revision 62147, including test that checks that the script is run in the current directory of the caller. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2385> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2385] run_setup can fail if the setup script uses __file__
Fred L. Drake, Jr. <[EMAIL PROTECTED]> added the comment: Updated patch to add restoring the current directory after running the setup.py script in run_script. Added file: http://bugs.python.org/file9937/run_script-restores-cwd.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2385> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2385] run_setup can fail if the setup script uses __file__
Changes by Fred L. Drake, Jr. <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file9936/run_script-restores-cwd.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2385> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2385] run_setup can fail if the setup script uses __file__
Fred L. Drake, Jr. <[EMAIL PROTECTED]> added the comment: It's also arguable that not providing __file__ was a bug, in which case that should be backported to Python 2.5.x. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2385> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1297] pyconfig.h not compatible with MS VC++ Express Edition
Fred L. Drake, Jr. <[EMAIL PROTECTED]> added the comment: On Apr 9, 2008, at 3:07 PM, Martin v. Löwis wrote: > Fred, can you remember what the rationale was? No; sorry. I didn't even remember that I'd ever built Python on Windows. Some things I've blocked out. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1297> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2102] New style vs. old style classes __ror__() operator overloading
Changes by Fred L. Drake, Jr. <[EMAIL PROTECTED]>: -- assignee: fdrake -> ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2102> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1163367] correct/clarify documentation for super
Fred L. Drake, Jr. <[EMAIL PROTECTED]> added the comment: Clearly, I've not gotten to this; unassigning from myself. Probably a good thing, since I'm one of the people who probably don't use it correctly in all cases. -- assignee: fdrake -> ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1163367> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
