[issue3953] __cmp__ still documented in 3.0rc1?
New submission from Hrvoje Nikšić [EMAIL PROTECTED]: __cmp__ is apparently still documented at http://docs.python.org/dev/3.0/reference/datamodel.html#object.__cmp__ . If it is going away for 3.0, it should be removed from the documentation as well. -- assignee: georg.brandl components: Documentation messages: 73692 nosy: georg.brandl, hniksic severity: normal status: open title: __cmp__ still documented in 3.0rc1? versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3953 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3944] faster long multiplication
Mark Dickinson [EMAIL PROTECTED] added the comment: Just to be clear: this patch halves the number of shifts and masks, asymptotically; it doesn't affect the number of adds and multiplies (except for saving a few additions to zero by setting the initial carry intelligently). Is that correct? It's quite surprising that the bit operations have such a large effect on the running time. Perhaps this is an argument for considering changing PyLong_SHIFT to 16 (or better, 32, since surely almost every compiler provides uint64_t or equivalent these days)? Though that would be quite an involved task. While I believe the idea is sound, the patch isn't quite correct---it's got some assertions that won't always hold. For example, with the patch, in a debug build of Python, I get: a = b = 2**30-1 [36413 refs] a*b Assertion failed: (carry = PyLong_MASK), function x_mul, file Objects/longobject.c, line 2228. Abort trap I'm fairly sure that the assert(carry = PyLong_MASK) doesn't matter, and that the assertion at the end of the main outer loop (assert(carry PyLong_SHIFT) == 0)) should still hold. But some more comments and analysis in the code would be good. For example, if carry = PyLong_MASK the the comment that 2*MASK + 2*MASK*MASK is contained in a twodigit isn't so useful. How big can carry get? -- nosy: +marketdickinson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3944 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706863] Failed to build Python 2.5.1 with sqlite3
Roumen Petrov [EMAIL PROTECTED] added the comment: If Jason patch resolve issue may I ask cygwincompiler.py to be modified too just in case if as result of issue2445 is decided to switch back ? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1706863 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2445] Use The CygwinCCompiler Under Cygwin
Roumen Petrov [EMAIL PROTECTED] added the comment:
May be check for compiler.compiler_type (from sysconfig.py ) has to be
replaced with a check for descendant classes of UnixCCompiler, i.e. to
include mingw32 too ?
Also CygwinCCompiler __init__ has to be reviewed too. As example :
-
# Hard-code GCC because that's what this is all about.
# XXX optimization, warnings etc. should be customizable.
self.set_executables(compiler='gcc -mcygwin -O -Wall',
.
-
May override in unexpected way settings from customize_compiler.
I thin that proposed modification in sysconfig.py with removing(or
replacing) of self.set_executables from CygwinCCompiler __init__ will
help me for issue3871 (cross building python for mingw32 with distutils).
As example I will remove a hack in the setup.py:
---
@@ -196,8 +196,26 @@
if compiler is not None:
(ccshared,cflags) =
sysconfig.get_config_vars('CCSHARED','CFLAGS')
args['compiler_so'] = compiler + ' ' + ccshared + ' ' + cflags
+
+# FIXME: Is next correct ?
+# To link modules we need LDSHARED passed to setup.py otherwise
+# distutils will use linker from build system if cross-compiling.
+linker_so = os.environ.get('LDSHARED')
+if linker_so is not None:
+args['linker_so'] = linker_so
+
self.compiler.set_executables(**args)
---
Thanks to Hirokazu who point me, in an another thread, that cygwin build
don't use CygwinCCompiler.
--
nosy: +rpetrov
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2445
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3951] Disable Py_USING_MEMORY_DEBUGGER!
STINNER Victor [EMAIL PROTECTED] added the comment: @loewis: your patch (revert.diff) includes a change in configure.in about OpenBSD !? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3451] Asymptotically faster divmod and str(long)
Mark Dickinson [EMAIL PROTECTED] added the comment: Thanks for the patch, Mario! I'll give a look when I get the chance. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3451 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross building python for mingw32 with distutils
Roumen Petrov [EMAIL PROTECTED] added the comment: For the protocol: issue2445 impact proposed patch. Also I finish the tests and I will upload soon new patch - I the current patch ( rpetrov, 2008-09-15 02:08) Modules/selectmodule.c isn't ported and this prevent socked and related modules to work. Also I understand the one of the reasons python 2.6x to be linked with msvcr90 - many of bugs related to math functions are fixed in this version of runtime. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3954] _hotshot: invalid error control in logreader()
STINNER Victor [EMAIL PROTECTED] added the comment: Oops, my previous patch always raise an error even on valid file :-p Here is a new patch with *an unit test* (yeah!). Added file: http://bugs.python.org/file11590/_hotshot_logreader2.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3954] _hotshot: invalid error control in logreader()
Changes by STINNER Victor [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file11589/_hotshot_logreader.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2445] Use The CygwinCCompiler Under Cygwin
Roumen Petrov [EMAIL PROTECTED] added the comment: P.S. : about: static_lib_extension = .dll.a - it is suffix for import library and unixccompiler.py.diff patch from issue1706863 propose dylib_lib_extension = .dll.a . ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2445 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2445] Use The CygwinCCompiler Under Cygwin
Roumen Petrov [EMAIL PROTECTED] added the comment: I forgot an another issue in CygwinCCompiler __init__: if gcc isn't version 2.91.57 then method will set dll_libraries to result of get_msvcr(), but the result may be is None. In this case link method fail on the line libraries.extend(self.dll_libraries). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2445 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3954] _hotshot: invalid error control in logreader()
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: The patch is good to me. gotos are perfectly allowed for this purpose. (to python committers: Should this kind of minor issues be fixed after 2.6rc2? This could as well wait until 2.6.1) -- nosy: +amaury.forgeotdarc resolution: - accepted ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue433024] SRE: (?flag) isn't properly scoped
Changes by Jeffrey C. Jacobs [EMAIL PROTECTED]: -- nosy: +timehorse ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue433024 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue433027] SRE: (?-flag) is not supported.
Changes by Jeffrey C. Jacobs [EMAIL PROTECTED]: -- nosy: +timehorse ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue433027 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue433028] SRE: (?flag:...) is not supported
Changes by Jeffrey C. Jacobs [EMAIL PROTECTED]: -- nosy: +timehorse ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue433028 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706863] Failed to build Python 2.5.1 with sqlite3
Jason Tishler [EMAIL PROTECTED] added the comment: Hirokazu Yamamoto wrote: Python is not using CCygwinCCompiler to build itself on cygwin. Which I why my patch modifies UnixCCompiler instead of CCygwinCCompiler. FWIW, my patch leverages the already existing Cygwin specific code in UnixCCompiler. So, is my patch acceptable? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1706863 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3825] Major reworking of Python 2.5.2 re module
Jeffrey C. Jacobs [EMAIL PROTECTED] added the comment: Matthew, I am really happy that you are making such progress on your engine, but can I PLEASE ask you to slow down for a moment? We have a lot of issues already listed in issue 2636 that is a catch-all for any Python 2.7 Regexp improvements, including your new engine, and I have been working frantically to try and document all the changes YOU are making here into the general Regexp 2.7 modification thread and setting up development trees in my Bazaar VCS repository for your work. There is also a recommended process for patching which makes it easier for the moderators to accept your patches which is to provide dis-entangled functionality and letting each improvement stand on its own two feet. In other words, let your engine stand ONLY on it's 2x speed improvements. We already have an implementation of Atomic Grouping / Possessive Qualifiers in issue 2636 but you have a version of your engine with both. We have no such 'feature-only' implementation for Variable-Length Look-Behind, for a Reverse flag, for Positionally Dependent modifier flags or modifier negation flags, as well as the zero-width Regular Expression split feature, though you and I completely agree these would all be great things to have! The more features you add to your engine as an all-or-nothing proposition, the less likely the moderators are going to be to adapt it because it's harder for them to examine the merits of each individual piece. That is why issue 2636 is broken up into items (currently 1 - 18, with your proposals bringing that up toward 22) and where alternate, combined features are provided if implementing 1 features would affect the implementation of another. Please understand that I personally have no problem with you redesigning large swaths of the Python Regular Expression engine. I would personally, like to see one of the design goals of any new engine not only be speed but better source comments because my main beef with the current engine is that it took me a month to understand and part of my redesign in issue 2636 9-1 was to add copious comments to the engine so that future developers would understand what was going on and be able to pick up from my work. I am not proposing we use my 9-1 engine because it is 8% slower than the current engine and I don't intend to propose anything slower. But it would be nice if you could add lots of comments to your engine so that others could help develop features against it. None the less, I will fully support your engine if it does indeed perform substantially and measurably faster and am happy to see all the Regexp issues you are finding are finally being implemented, all be it entangled with your engine. But let's return to the fundamentals of what you propose IN THIS THREAD, which simply to propose a new Regexp Engine which is 2x faster than the existing engine (Which I have allocated item 9-2 in the issue 2636 thread). I am not trying to put more work on your hands -- in fact, what I am trying to do is get us to co-operate on a better python Regexp Engine so that I can help you to achieve your goals. Please read issue 2636 and join the discussion there; feel free to add any new items you feel are missing from my existing list. And remember, each new feature needs tests and documentation changes. I have been doing each for any feature I undertake and would be happy to share those skills with you. Let's work together to see your engine be the new model, okay? Thanks. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3825 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1759169] clean up Solaris port and allow C99 extension modules
Zooko O'Whielacronx [EMAIL PROTECTED] added the comment: Sorry I didn't get back to this ticket, MvL. Recently someone trying to build the Tahoe distributed filesystem on Solaris had a problem: http://allmydata.org/pipermail/tahoe-dev/2008-September/000789.html They had built Python 2.5 themselves from source. It turned out to be this issue: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6395191 Which is that g++ on Solaris fails when _XOPEN_SOURCE_EXTENDED is defined. This reminded me of this ticket, so here I am again. So, here is the port of Python to Solaris that is maintained by the Solaris engineers: http://src.opensolaris.org/source/xref/jds/spec-files/trunk/SUNWPython.spec It contains the following stanza: 146 # These #define's break the build with gcc and cause problems when 147 # building c99 compliant python modules 148 perl -pi -e 's/^(#define _POSIX_C_SOURCE.*)/\/* $1 *\//' pyconfig.h 149 perl -pi -e 's/^(#define _XOPEN_SOURCE.*)/\/* $1 *\//' pyconfig.h 150 perl -pi -e 's/^(#define _XOPEN_SOURCE_EXTENDED.*)/\/* $1 *\//' pyconfig.h This shows that the Python that comes with Solaris has, for a long time now, had these #define's stripped out of the pyconfig.h. Why? Well, I asked the Solaris engineers about it on IRC, and they were very nice and helpful, and they said, if I am remembering correctly, that Solaris doesn't use these #define's in the way that we Python people think. #defining _XOPEN_SOURCE_EXTENDED on Solaris is *not* understood by the Solaris runtime as a request for XPG4v2 (UNIX98) features to be supported, but more as a declaration that the code we are compiling was written for XPG4v2. So, for example, this disables C99, because after all C99 wasn't available in XPG4v2. It also apparently breaks g++, but that is by accident rather than design. In any case, the Solaris engineers assured me that rather than figuring out which unixy features are turned on by which #defines, we should instead #define __EXTENSIONS__ and then assume all the features we can eat. Whether this is true in general remains to be seen, but apparently _POSIX_C_SOURCE, _XOPEN_SOURCE, and _XOPEN_SOURCE_EXTENDED, at least, are proven to be unnecessary on Solaris by the fact that the version of Python that has been shipping with Solaris for who knows how long has them stripped out. Therefore, I propose to apply my patch so that we do not turn on _XOPEN_SOURCE but we do turn on __EXTENSIONS__, when building for Solaris. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1759169 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3824] test_tarfile fails on cygwin (unicode decode error)
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Doesn't getgrgid() return the untranslated content of /etc/group? Then the encoding of this file is relevant. On cygwin, mkgroup -l is often (exclusively?) used to generate this /etc/group, extracting the user definitions from the Windows settings. Its source code http://www.google.com/codesearch?q=file:mkgroup.c+package:cygwin-1.5 shows that it uses MBCS to encode strings. Maybe we should start considering cygwin as a posix platform with win32 features; but I am not sure to like this idea. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3824 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3955] maybe doctest doesn't understand unicode_literals?
New submission from Mark Summerfield [EMAIL PROTECTED]: # This program works fine with Python 2.5 and 2.6: def f(): f() 'xyz' return xyz if __name__ == __main__: import doctest doctest.testmod() But if you put the statement from __future__ import unicode_literals at the start then it fails: File /tmp/test.py, line 5, in __main__.f Failed example: f() Expected: 'xyz' Got: u'xyz' I don't know if it is a bug or a feature but I didn't see any mention of it in the bugs or docs so thought I'd mention it. -- components: Library (Lib) messages: 73710 nosy: mark severity: normal status: open title: maybe doctest doesn't understand unicode_literals? type: behavior versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3955 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3511] Incorrect charset range handling with ignore case flag?
Changes by Jeffrey C. Jacobs [EMAIL PROTECTED]: -- nosy: +timehorse ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3511 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3511] Incorrect charset range handling with ignore case flag?
Jeffrey C. Jacobs [EMAIL PROTECTED] added the comment: I think this is even more complicated when you consider that localization my be an issue. Consider Á: is this grammatically before A or after a? From a character set point of view, it is typically after a but when Locale is taken into account, all that is done is there is a change to relative ordering, so Á appears somewhere before A and B. But when this is done, does that mean that [9-Á] is going to cover ALL uppercase and ALL lowercase and ALL characters with ord from 91 to 96 and 123 to 127 and all kinds of other UNICODE symbols? And how will this effect case-insensitivity. In a sense, I think it may only be safe to say that character class ranges are ONLY appropriate over Alphabetic character ranges or numeric character ranges, since the order of the ASCII symbols between 0 and 47, 56 and 64, 91 adn 96 and 123 and 127, though well-defined, are none the less implementation dependent. When we bring UNICODE into this, things get even more befuddled with some Latin characters in Latin-1, some in Latin-2, Cyrillic, Hebrew, Arabic, Chinese, Japanese and Korean character sets just to name a few of the most common! And how does a total ordering of characters apply to them? In the end, I think it's just dangerous to define character group ranges that span the gap BETWEEN numbers and alphabetics. Instead, I think a better solution is simply to implement Emacs / Perl style named character classes as in issue 2636 sub-item 8. I do agree this is a problem, but as I see it, the solution may not be that simple, especially in a UNICODE world. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3511 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3956] turtle.py - bug in Screen.__init__()
New submission from Gregor Lingl [EMAIL PROTECTED]: There is a bug in Screen.__init__() (The Screen class uses the Borg idiom to simulate a Singleton). This bug is demonstrated best interactively from IDLE (using the -n switch) like this: from turtle import Screen, Turtle t = Turtle() t.fd(100) # idea: let's have a yellow background, so we need # *the* screen s = Screen() # the drawing vanishes s.turtles() [] This is undesired behaviour. Instead the Screen() call should leave the drawings an the turtles untouched and return the already existing Screen. So the call of turtles() would result in something like: s.turtles() [turtle.Turtle object at 0x01490330] This is accomplished by the patch described in the attached file turtle.diff Of course sequences of commands like those shown in the interactive session above do not occur in well designed scripts, but they may well occur during sessions of students in interactive classroom use. Two more important notes: (1) This patch is already done in turtle.py for Python 3.0. So in 2.6 it would ensure that Turtles and the Screen show identical behaviour in both versions. (2) This patch makes necessary one other patch in turtleDemo.py - in the Demo directory - which is shown in the attached turtleDemo.diff turtleDemo.py is not a normal turtle application but a GUI - utility designed to run a series of 'normal' turtle - apps conforming to some simple rules (These apps in most cases use a Screen()). So when switching from one to another demo script within turtleDemo one wants to reinitialize the Canvas - what is just the contrary of what one wants normally as explained above. This is accomplished by this patch of turtleDemo.py. (This patch is also already done for Python 3.0) -- files: turtle.diff keywords: patch messages: 73712 nosy: benjamin.peterson, gregorlingl, loewis severity: normal status: open title: turtle.py - bug in Screen.__init__() type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file11591/turtle.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3956] turtle.py - bug in Screen.__init__()
Gregor Lingl [EMAIL PROTECTED] added the comment: Do the patch of turtleDemo.py if and only if the patch of turtle.py is accepted. Added file: http://bugs.python.org/file11592/turtleDemo.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Matthew Barnett [EMAIL PROTECTED] added the comment: Comparing item 2 and item 3, I think that item 3 is the Pythonic choice and item 2 is a bad idea. Item 4: back-references in the pattern are like \1 and (?P=name), not \g1 or \gname, and in the replacement string are like \g1 and \gname, not \1 (or (?P=name)). I'd like to suggest that back-references in the pattern also include \g1 and \gname and \g-1 for relative back-references. Interestingly, Perl names groups with (?name...) whereas Python uses (?Pname...). A permissible alternative? -- nosy: +mrabarnett ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3957] [contextlib] Reverse order of locking
New submission from David Naylor [EMAIL PROTECTED]: Overview: Add a generator that will revert the order applied to a with statement. Motivation: Often with threaded applications one needs to do a certain task outside of a lock but while inside a greater block of code protected by a lock. e.g: with lock: BLOCK1 lock.release() try: BLOCK2 finally: lock.acquire() BLOCK3 but with an inverter for a with statement it becomes: with lock: BLOCK1 with invert(lock): BLOCK2 BLOCK3 [Of course there are many other possible uses for this...] Implementation: def invert(thing): thing.__exit__(None, None, None) yield thing thing.__enter__() Issues: Normal exception handling will not take place (however for locks and the like this is not an issue) -- components: Library (Lib) messages: 73715 nosy: DragonSA severity: normal status: open title: [contextlib] Reverse order of locking type: feature request versions: Python 2.6, Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3957 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3957] [contextlib] Reverse order of locking
David Naylor [EMAIL PROTECTED] added the comment: Apologies, obviously the invert function should be preceded by an @contextmanager to become: @contextmanager def invert(thing): thing.__exit__(None, None, None) yield thing thing.__enter__() [Although there may be a better way of doing this, perhaps as a class?] ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3957 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Jeffrey C. Jacobs [EMAIL PROTECTED] added the comment: Thanks for weighing in Matthew! Yeah, I do get some flack for item 2 because originally item 3 wasn't supposed to cover named groups but on investigation it made sense that it should. I still prefer 2 over-all but the nice thing about them being separate items is that we can accept 2 or 3 or both or neither, and for the most part development for the first phase of 2 is complete though there is still IMHO the issue of UNICODE name groups (visa-vi item 14) and the name collision problem which I propose fixing with an Attribute / re.A flag. So, I think it may end up that we could support both 3 by default and 2 via a flag or maybe 3 and 2 both but with 2 as is, with name collisions hidden (i.e. if you have r'(?Pstring...)' as your capture group, typing m.string will still give you the original comparison string, as per the current python documentation) but have collision-checking via the Attribute flag so that with r'(?A)(?Pstring...)' would not compile because string is a reserved word. Your interpretation of 4 matches mine, though, and I would definitely suggest using Perl's \g-n notation for relative back-references, but further, I was thinking, if not part of 4, part of the catch-all item 11 to add support for Perl's (?name...) as a synonym for Python's (?Pname...) and Perl's \kname for Python's (?P=name) notation. The evolution of Perl's name group is actually interesting. Years ago, Guido had a conversation with Larry Wall about using the (?P...) capture sequence for python-specific Regular Expression blocks. So Python went ahead and implemented named capture groups. Years later, the Perl folks thought named capture groups were a neat idea and adapted them in the (?..) form because Python had restricted the (?P...) notation to themselves so they couldn't use our even if they wanted to. Now, though, with Perl adapting (?..), I think it inevitable that Java and even C++ may see this as the defacto standard. So I 100% agree, we should consider supporting (?name...) in the parser. Oh, and as I suggested in Issue 3825, I have these new item proposals: Item 18: Add a re.REVERSE, re.R (?r) flag for reversing the direction of the String Evaluation against a given Regular Expression pattern. See issue 516762, as implemented in Issue 3825. Item 19: Make various in-line flags positionally dependant, for example (?i) makes the pattern before this case-sensitive but after it case-insensitive. See Issue 433024, as implemented in Issue 3825. Item 20: All the negation of in-line flags to cancel their effect in conditionally flagged expressions for example (?-i). See Issue 433027, as implemented in Issue 3825. Item 21: Allow for scoped flagged expressions, i.e. (?i:...), where the flag(s) is applied to the expression within the parenthesis. See Issue 433028, as implemented in Issue 3825. Item 22: Zero-width regular expression split: when splitting via a regular expression of Zero-length, this should return an expression equivalent to splitting at each character boundary, with a null string at the beginning and end representing the space before the first and after the last character. See issue 3262. Item 23: Character class ranges over case-insensitive matches, i.e. does (?i)[9-A] contain '_' , whose ord is greater than the ord of 'A' and less than the ord of 'a'. See issue 5311. And I shall create a bazaar repository for your current development line with the unfortunately unwieldy name of lp:~timehorse/python/issue2636-01+09-02+17+18+19+20+21 as that would, AFAICT, cover all the items you've fixed in your latest patch. Anyway, great work Matthew and I look forward to working with you on Regexp 2.7 as you do great work! ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3958] strage default value behaviour
New submission from dominik.holler [EMAIL PROTECTED]: The behaviour is changing, if I toogle comment lines 10 + 11. Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32 -- components: None files: test.py messages: 73718 nosy: dominik.holler severity: normal status: open title: strage default value behaviour versions: Python 2.4, Python 2.5 Added file: http://bugs.python.org/file11593/test.py ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3958] strage default value behaviour
Changes by dominik.holler [EMAIL PROTECTED]: Added file: http://bugs.python.org/file11594/index.html ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1647489] zero-length match confuses re.finditer()
Matthew Barnett [EMAIL PROTECTED] added the comment: This also affects re.findall(). -- nosy: +mrabarnett ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1647489 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1856] shutdown (exit) can hang or segfault with daemon threads running
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: The threads don't have to be daemons: sys.exit() calls Py_Finalize() without waiting for non-daemons threads. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1856 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3944] faster long multiplication
Pernici Mario [EMAIL PROTECTED] added the comment: Yes, I think that the speed-up is due to reducing the number of shifts and masks. Changing PyLong_SHIFT to 16 would be complicated; for instance in v_iadd() carry could not be a digit of 16 bits anymore; writing code specific for 64 bit machines would surely improve performance; maybe with PyLong_SHIFT=30 few changes to the code would be needed? I did not modify the case a = b. I changed the documentation, which was wrong, adding detailed bounds on carry in the various steps to check that it does not overflow. I corrected the wrong assertion (carry = PyLong_MASK). -- keywords: +patch Added file: http://bugs.python.org/file11595/longobject1.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3944 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3958] strage default value behaviour
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Your script is subject to the shared default value syndrome, explained here: http://www.python.org/doc/faq/general/#why-are-default-values-shared-between-objects As indicated in the FAQ, your function could be rewritten like this: def getElementsByAttrib(self, value, AName=ID-REF, list=None): if list is None: list = [] ... to have a less surprising behavior. -- nosy: +amaury.forgeotdarc resolution: - invalid status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Matthew Barnett [EMAIL PROTECTED] added the comment: Regarding item 22: there's also #1647489 (zero-length match confuses re.finditer()). This had me stumped for a while, but I might have a solution. I'll see whether it'll fix item 22 too. I wasn't planning on doing any more major changes on my branch, just tweaking and commenting and seeing whether I've missed any tricks in the speed stakes. Half the task is finding out what's achievable, and how! ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3950] turtle.py: bug in TurtleScreenBase._drawimage
Georg Brandl [EMAIL PROTECTED] added the comment: Gregor doesn't have commit rights. Patch looks OK, would you apply it please, Ben? -- assignee: - benjamin.peterson nosy: +georg.brandl resolution: - accepted ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3950 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3956] turtle.py - bug in Screen.__init__()
Georg Brandl [EMAIL PROTECTED] added the comment: Looks ok, like the 3.0 code. Benjamin, please review and commit. -- assignee: - benjamin.peterson nosy: +georg.brandl resolution: - accepted ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3954] _hotshot: invalid error control in logreader()
Georg Brandl [EMAIL PROTECTED] added the comment: Looks fine. Since it is minor, why not commit it now? -- nosy: +georg.brandl ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3954] _hotshot: invalid error control in logreader()
STINNER Victor [EMAIL PROTECTED] added the comment: @georg: give me a svn access and i will commit it ;-) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3955] maybe doctest doesn't understand unicode_literals?
Georg Brandl [EMAIL PROTECTED] added the comment: It certainly isn't a feature. I don't immediately see how to fix it, though. unicode_literals doesn't change the repr() of unicode objects (it obviously can't, since that change would not be module-local). Let's try to get a comment from Uncle Timmy... -- assignee: - tim_one nosy: +georg.brandl, tim_one ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3955 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Georg Brandl [EMAIL PROTECTED] added the comment: Though I can't look at the code at this time, I just want to express how good it feels that you both are doing these great things for regular expressions in Python! Especially atomic grouping is something I've often wished for when writing lexers for Pygments... Keep up the good work! -- nosy: +georg.brandl ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3824] test_tarfile fails on cygwin (unicode decode error)
Hirokazu Yamamoto [EMAIL PROTECTED] added the comment: Doesn't getgrgid() return the untranslated content of /etc/group? Then the encoding of this file is relevant. Yes, /etc/group contains なし as gr_name in MBCS,（なし means nothing）and I can print it with puts() in grpmodule.c, so it shouldn't be translated. Maybe we should start considering cygwin as a posix platform with win32 features; but I am not sure to like this idea. Me neigher. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3824 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3428] httplib.HTTPMessage undocumented
Changes by Georg Brandl [EMAIL PROTECTED]: -- components: +Documentation -Documentation tools (Sphinx) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3428 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3875] provide a cmem role
Georg Brandl [EMAIL PROTECTED] added the comment: Added in r66606. -- resolution: - accepted status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3875 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3875] provide a cmem role
Georg Brandl [EMAIL PROTECTED] added the comment: (It's called cmember). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3875 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3909] Building PDF documentation from tex files
Georg Brandl [EMAIL PROTECTED] added the comment: Hmm, I can't really tell what may cause the Too many } error. Can you try and play around with sphinx.sty, commenting out stuff, to find where it comes from? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3909 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3547] Ctypes is confused by bitfields of varying integer types
Fredrik Lundh [EMAIL PROTECTED] added the comment: Looks fine to me, except for the comment in the test suite. Should +# MS compilers do NOT combine c_short and c_int into +# one field, gcc doesn't. perhaps be +# MS compilers do NOT combine c_short and c_int into +# one field, gcc do. ? Is using explicit tests for MSVC vs. GCC a good idea, btw? What about other compilers? Can the test be changed to accept either value? -- nosy: +effbot ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3547 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3547] Ctypes is confused by bitfields of varying integer types
Skip Montanaro [EMAIL PROTECTED] added the comment: Looks reasonable, though I'm no ctypes maven. Trivial little nit: In the comment just before the start of CField_FromDesc it says, in part: * Expects the size, index and offset for the current field in *psize and * *poffset, stores the total size so far in *psize, the offset for the next Note that it identifies three values (size, index, offset) as stored in two locations (*psize and *poffset). Seems like some sort of mismatch to me. -- nosy: +skip.montanaro ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3547 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1647489] zero-length match confuses re.finditer()
Changes by Jeffrey C. Jacobs [EMAIL PROTECTED]: -- nosy: +timehorse ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1647489 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1647489] zero-length match confuses re.finditer()
Matthew Barnett [EMAIL PROTECTED] added the comment: What should: [m.groups() for m in re.finditer(r'(^z*)|(^q*)|(\w+)', 'abc')] return? Should the second group also yield a zero-width match before the third group is tried? I think it probably should. Does Perl? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1647489 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3547] Ctypes is confused by bitfields of varying integer types
Thomas Heller [EMAIL PROTECTED] added the comment: Fredrik Lundh schrieb: Looks fine to me, except for the comment in the test suite. Should +# MS compilers do NOT combine c_short and c_int into +# one field, gcc doesn't. perhaps be +# MS compilers do NOT combine c_short and c_int into +# one field, gcc do. Sure. But isn't this correct (or better) english, instead? Is using explicit tests for MSVC vs. GCC a good idea, btw? What about other compilers? Can the test be changed to accept either value? Well, MSVC and GCC are the only compilers that I use (and that are tested on the buildbots, afaik). If a cygwin compiled Python, for example, fails this test then of course the test must be changed. Thanks. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3547 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3547] Ctypes is confused by bitfields of varying integer types
Thomas Heller [EMAIL PROTECTED] added the comment: Skip Montanaro schrieb: Looks reasonable, though I'm no ctypes maven. Trivial little nit: In the comment just before the start of CField_FromDesc it says, in part: * Expects the size, index and offset for the current field in *psize and * *poffset, stores the total size so far in *psize, the offset for the next Note that it identifies three values (size, index, offset) as stored in two locations (*psize and *poffset). Seems like some sort of mismatch to me. Unfortunately this is not the only comment that is out of date in the ctypes sources. I wanted to touch as little code as possible in this patch. Thanks. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3547 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3547] Ctypes is confused by bitfields of varying integer types
Fredrik Lundh [EMAIL PROTECTED] added the comment: Do should be does, right. Not enough coffee today :) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3547 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1647489] zero-length match confuses re.finditer()
Jeffrey C. Jacobs [EMAIL PROTECTED] added the comment: Hmmm. This strikes me as a bug, beyond the realm of Issue 3262. The two items may be related, but the dropping of the 'a' seems like unexpected behaviour that I doubt any current code is expecting to occur. Clearly, what is going on is that the Engine starts scanning at the 'a', finds the Zero-Width match and, having found a match, increments its pointer within the input string, thus skipping the 'a' when it matches 'bc'. If it is indeed a bug, I think this should be considered for inclusion in Python 2.6 rather than being part of the new Engine Design in Issue 3626. I think the solution would simply be to not increment the ptr (which points to the input string) when findall / finditer encounters a Zero-Width match. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1647489 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1647489] zero-length match confuses re.finditer()
Jeffrey C. Jacobs [EMAIL PROTECTED] added the comment: Never mind inclusion in 2.6 as no-one has repeated this bug in re-world examples yet so it's going to have to wait for the Regexp 2.7 engine in issue 2636. -- versions: +Python 2.7 -Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1647489 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3951] Disable Py_USING_MEMORY_DEBUGGER!
Changes by Martin v. Löwis [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file11588/revert.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3951] Disable Py_USING_MEMORY_DEBUGGER!
Martin v. Löwis [EMAIL PROTECTED] added the comment: Sorry about that - let me retry. Added file: http://bugs.python.org/file11596/revert.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] platform.dist() has unpredictable result under Linux
Zooko O'Whielacronx [EMAIL PROTECTED] added the comment: Well, for what it is worth I've updated the custom detect linux distribution code in Tahoe yet again. The current version first tries to parse /etc/lsb-version (fast, gives a good answer on Ubuntu, and hopefully at least semi-standardized), then invokes platform.dist() (fast, customized, but gives a bad answer on Ubuntu), and then if platform.dist() returns an empty distribution or empty release (which I'm not sure if that is even possible), it invokes lsb_release -a in a subprocess (slow, totally standardized). Here's the patch: http://allmydata.org/trac/tahoe/changeset/2981 Running it on the Tahoe buildbot shows that we currently have the followings kinds of buildslaves: http://allmydata.org/buildbot/waterfall?show_events=true Linux-Ubuntu_6.06-i686-32bit, Linux-Ubuntu_6.10-i686-32bit, Linux-Ubuntu_7.10-i686-32bit, SunOS-5.11-i86pc-i386-32bit, Linux-Ubuntu_7.04-i686-32bit, Linux-debian_4.0-i686-32bit, Linux-Ubuntu_8.04-i686-32bit, Darwin-9.4.0-i386-32bit, Linux-Ubuntu_8.04-x86_64-64bit, Windows-XP-5.1.2600-SP2, CYGWIN_NT-5.1-1.5.25-0.156-4-2-i686-32bit-WindowsPE ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1322 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1647489] zero-length match confuses re.finditer()
Jeffrey C. Jacobs [EMAIL PROTECTED] added the comment: Ah, I see the problem, if ptr is not incremented, then it will keep matching the first expression, (^z*), so it would have to both 'skip' the 'a' and NOT skip the 'a'. Hmm. You're right, Matthew, this is pretty complicated. Now, for your expression, Matthew, r'(z*)|(^q*)|(\w+)', Perl gives: ,undef,undef undef,undef,abc ,undef,undef Meaning it doesn't even bother matching the ^q* since the ^z* matches first. This seems the logical behaviour and fits with the idea that a Zero-Width match would both only match once and NOT consume any characters. An internal flag would just have to be created to tell the 2 find functions whether the current value of ptr would allow for a No Zero-Width Match option on second go-around. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1647489 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3958] strage default value behaviour
dominik.holler [EMAIL PROTECTED] added the comment: thx sorry reporting this bug ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706863] Failed to build Python 2.5.1 with sqlite3
Hirokazu Yamamoto [EMAIL PROTECTED] added the comment: So, is my patch acceptable? Umm, it works, but I'm not sure we can call import library as dylib... If it's not problem, I think your patch is fine. # I had considered attached patch experimental_distutils.patch. It's little adhoky, I'm not sure this patch is acceptable. -- components: +Distutils Added file: http://bugs.python.org/file11597/experimental_distutils.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1706863 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3824] test_tarfile fails on cygwin (unicode decode error)
Martin v. Löwis [EMAIL PROTECTED] added the comment: Doesn't getgrgid() return the untranslated content of /etc/group? Then the encoding of this file is relevant. That certainly depends on the implementation of getgrgid. On some systems, it uses NIS, LDAP, or a relational database in addition to or instead of /etc/group. I don't think POSIX specifies the charset of gr_name, except perhaps implicitly by inheriting the notion of execution character set from C, which proposes that all char* should have the same interpretation. In POSIX, the character set comes from the locale. The getgrid man page gives an example demonstrating that you are supposed to be able to printf() gr_name using %s, which suggests that it should have the locale's encoding. In Cygwin, I have no doubt that the implementation literally copies the encoding untranslated. I would claim this to be a bug in Cygwin. A quality POSIX implementation would convert the /etc/group encoding to the locale's encoding (just as it should when fetching the data from LDAP). Maybe we should start considering cygwin as a posix platform with win32 features; but I am not sure to like this idea. If it is desired that we support this specific implementation aspect, we can certainly special-case Cygwin in getgrgid. However, I would prefer if this issue was discussed with the Cygwin people first, suggesting that it might be a Cygwin bug (one that it certainly shares with many other POSIX implementations - people just don't use non-ASCII characters in /etc/group). If Cygwin ever changes its implementation in that respect, we would need to have a way for telling which specific implementation is being used. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3824 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3956] turtle.py - bug in Screen.__init__()
Martin v. Löwis [EMAIL PROTECTED] added the comment: I'm opposed to this patch. As a design principle, any class should always call its base class' __init__, unless that is known to be empty. With this patch, the base __init__ call becomes conditional, which hints at a design bug of the entire class hierarchy. I don't quite understand *what* the problem is. If Screen is intended to be a singleton, then the right fix would be to make Screen a function, which maintains a singleton reference, and Screen be renamed to _Screen. The fact that the same design bug already exists in 3.0 doesn't mean it should be backported to 2.6. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3956] turtle.py - bug in Screen.__init__()
Martin v. Löwis [EMAIL PROTECTED] added the comment: As a follow-up, I also don't understand the two if blocks in Screen.__init__: if there is meant to be a single Screen instance anyway, why have _root, _canvas, and _title as class variables, whereas everything else is in (shared) instance variables? How could _root be initialized, and _canvas not (or vice versa)? And why is Turtle._screen being set to the last Screen instance being created (even under this patch), whereas all other initialization is keyed to the creation of the first Screen instance? This code could surely use some comments. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3943] IDLE won't start in 3.0rc1 Subprocess didn't make connection....
Robert Yodlowski [EMAIL PROTECTED] added the comment: Amaury, I did as you suggested - running idle.py directly both from a command line and by clicking on it and the results were the same. Each time, I got the same error message window as before. In addition, several seconds before the error window came up I got the following traceback in the command window: C:\Python30python Lib/idlelib/idle.py Traceback (most recent call last): File string, line 1, in module File C:\Python30\lib\idlelib\run.py, line 76, in main sockthread.set_daemon(True) AttributeError: 'Thread' object has no attribute 'set_daemon' I hope this helps. ...Bob ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Jeffrey C. Jacobs [EMAIL PROTECTED] added the comment: Good catch on issue 1647489 Matthew; it looks like this is where that bug fix will end up going. But, I am unsure if the solution for this issue is going to be the same as for 3262. I think the solution here is to add an internal flag that will keep track of whether the current character had previously participated in a Zero-Width match and thus not allow any subsequent zero-width matches associated beyond the first, and at the same time not consuming any characters in a Zero-width match. Thus, I have allocated this fix as Item 24, but it may be later merged with 22 if the solutions turn out to be more or less the same, likely via a 22+24 thread. The main difference, though, as I see it, is that the change in 24 may be considered a bug where the general consensus of 22 is that it is more of a feature request and given Guido's acceptance of a flag-based approach, I suggest we allocate re.ZEROWIDTH, re.Z and (?z) flags to turn on the behaviour you and I expect, but still think that be best as a 2.7 / 3.1 solution. I would also like to add a from __futurue__ import ZeroWidthRegularExpressions or some such to make this the default behaviour so that by version 3.2 it may indeed be considered the default. Anyway, I've allocated all the new items in the launchpad repository so feel free to go to http://www.bazaar-vcs.org/ and install Bazaar for windows so you can download any of the individual item development threads and try them out for yourself. Also, please consider setting up a free launchpad account of your very own so that I can perhaps create a group that would allow us to better share development. Thanks again Matthew for all your greatly appreciated contributions! ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted
Nick Coghlan [EMAIL PROTECTED] added the comment: The 3.0 forward port of r66386 still needs a once over before being committed (there were enough differences that I don't think the review of the 2.6 version is enough to cover the 3.0 version as well). Once that is done, then this issue can be closed. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3781 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1647489] zero-length match confuses re.finditer()
Matthew Barnett [EMAIL PROTECTED] added the comment: What about r'(^z*)|(q*)|(\w+)'? I could imagine that the first group could match only at the start of the string, but if the second group doesn't have that restriction then it could match the second time, and only after that could the third match, if you see what I mean. (The previous example had (^q*) so it couldn't match because the first group has already matched at the start of the string and we've already advanced beyond that, even though by no characters!) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1647489 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3951] Disable Py_USING_MEMORY_DEBUGGER!
Benjamin Peterson [EMAIL PROTECTED] added the comment: Looks good to me. -- keywords: -needs review nosy: +benjamin.peterson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3950] turtle.py: bug in TurtleScreenBase._drawimage
Benjamin Peterson [EMAIL PROTECTED] added the comment: Done in r66614. Georg, according to http://python.org/dev/committers and r64063, Gregor does have commit access. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3950 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3950] turtle.py: bug in TurtleScreenBase._drawimage
Georg Brandl [EMAIL PROTECTED] added the comment: My apologies then. -- status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3950 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
New submission from Guido van Rossum [EMAIL PROTECTED]: Google just released ipaddr.py, a module that knows how to manipulate IP addresses (both IPv4 and IPv6). I have nothing to do with this module, but I suggest considering it for inclusion in the standard library. It fills a gap for address manipulations that will become more important to fill as IPv6 becomes more widespread. -- messages: 73761 nosy: gvanrossum priority: normal severity: normal status: open title: Add Google's ipaddr.py to the stdlib versions: Python 2.7, Python 3.1 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Benjamin Peterson [EMAIL PROTECTED] added the comment: Where can we find this? -- nosy: +benjamin.peterson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Guido van Rossum [EMAIL PROTECTED] added the comment: It would help if I added a link to the Google release: http://code.google.com/p/ipaddr-py/ Description: An IPv4/IPv6 manipulation library in Python. This library is used to create/poke/manipulate IPv4 and IPv6 addresses and prefixes. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Benjamin Peterson [EMAIL PROTECTED] added the comment: Almost time machine. :) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Changes by Matthew Smart [EMAIL PROTECTED]: -- nosy: +mattsmart ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Changes by Michael Shields [EMAIL PROTECTED]: -- nosy: +shields ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Jeffrey C. Jacobs [EMAIL PROTECTED] added the comment: I've moved all the development branches to the ~pythonregexp2.7 team so that we can work collaboratively. You just need to install Bazaar, join www.launchpad.net, upload your public SSH key and then request to be added to the pythonregexp2.7 team. At that point, you can check out any code via: bzr co lp:~pythonregexp2.7/python/issue2636-* This should make co-operative development easier. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3826] BaseHTTPRequestHandler depends on GC to close connections
Changes by Rafael Zanella [EMAIL PROTECTED]: -- nosy: +zanella ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3826 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Martin v. Löwis [EMAIL PROTECTED] added the comment: I see a list of owners in the code (although it's difficult to infer real names or email addresses from that list). I think we should not include the code without their explicit approval. The question will then always be: what is the official master copy of the code? The one in Python, or the one on Google code? Whose responsibility would it be to keep those synchronized, and incorporate changes from one copy into the other? I would prefer if the copy in Python (say, 2.7) becomes the master copy, and the copy on Google code eventually disappears (when interest in older Python versions has died). I would object to a mere fork of the code (i.e. where one of the regular Python committers incorporates, from time to time, the changes that Google made) -- nosy: +loewis ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3951] Disable Py_USING_MEMORY_DEBUGGER!
Martin v. Löwis [EMAIL PROTECTED] added the comment: Committed as r66616 and r66617 -- assignee: loewis - priority: release blocker - normal ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
pmoody [EMAIL PROTECTED] added the comment: as one of the owners listed in the code.google.com project (same name), and the original author, you certainly have my approval for inclusion in python. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
