[ python-Bugs-1391872 ] floating point literals don't work in non-US locale in 2.5
Bugs item #1391872, was opened at 2005-12-28 03:01
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Fredrik Lundh (effbot)
Assigned to: Neal Norwitz (nnorwitz)
Summary: floating point literals don't work in non-US locale in 2.5
Initial Comment:
According to reports on comp.lang.python, the current
SVN trunk fails to handle floating point literals if
the locale is changed:
>>> import locale
>>> locale.setlocale(locale.LC_ALL, '')
'German_Germany.1252'
>>> 3.141592
3.0
This works just fine in 2.4.2.
See the later portions of the thread "build
curiosities of svn head (on WinXP)" for more details:
http://groups.google.com/group/comp.lang.python/browse_
frm/thread/226584dd47047bb6/e609cb1a0d47e98f
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-20 00:02
Message:
Logged In: YES
user_id=33168
Keeping open as a reminder to fix the regression tests
running on the PSF box every 12 hours. Need to have a run
in a different locale.
--
Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 00:11
Message:
Logged In: YES
user_id=1188172
Neal, you checked in a workaround in test__locale for eu_ES.
Can this be closed then?
--
Comment By: Brett Cannon (bcannon)
Date: 2006-01-18 23:12
Message:
Logged In: YES
user_id=357491
This still fails on OS X 10.4.4:
AssertionError: using eval('3.14') failed for eu_ES
This is using rev. 42094.
--
Comment By: Fredrik Lundh (effbot)
Date: 2005-12-29 12:37
Message:
Logged In: YES
user_id=38376
Verified and fixed in SVN. Assinging to Neal, in case
he wants to add an extra locale test pass to his build
robot.
--
Comment By: Fredrik Lundh (effbot)
Date: 2005-12-29 10:52
Message:
Logged In: YES
user_id=38376
Looks good to me. I'll check this in shortly.
--
Comment By: Hye-Shik Chang (perky)
Date: 2005-12-29 00:22
Message:
Logged In: YES
user_id=55188
The new patch tests it along with other locale-dependent
tests on test__locale. How about this?
--
Comment By: Fredrik Lundh (effbot)
Date: 2005-12-28 11:00
Message:
Logged In: YES
user_id=38376
I'm not sure you can make too many assumptions about
the locale in the test suite, but I'm pretty sure that
it would be a good idea to let your "build robot" run
the test suite twice; once with the standard C locale,
and once with a non-US locale (e.g. sv_SE.utf8 which
does include some odd characters, different date and
money formats, and a decimal comma).
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-28 10:16
Message:
Logged In: YES
user_id=33168
Wow, I thought for sure I broke it with my recent patch to remove support for
hex floats. But it looks like just an AST problem (which I can be blamed for
too :-). The patch looks fine, but could you add tests so this doesn't happen
again. Thanks!
I'll be back in a week and try to fix it then if no one gets back to it.
--
Comment By: Hye-Shik Chang (perky)
Date: 2005-12-28 06:04
Message:
Logged In: YES
user_id=55188
Okay. Here's a fix.
--
Comment By: Hye-Shik Chang (perky)
Date: 2005-12-28 05:41
Message:
Logged In: YES
user_id=55188
This looks like a bug introduced by AST import;
r39757 is okay but r39762 has such an error.
--
Comment By: Fredrik Lundh (effbot)
Date: 2005-12-28 03:02
Message:
Logged In: YES
user_id=38376
I just confirmed this on Unix:
$ export LANG=sv_SE.utf8
$ ./python
Python 2.5a0 (41806M, Dec 25 2005, 12:12:29)
[GCC 2.96 2731 (Red Hat Linux 7.2 2.96-112.7.2)] on
linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> 3.14
3.1401
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
'sv_SE.utf8'
>>> 3.14
3.0
>>>
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470
_
[ python-Bugs-1367183 ] inspect.getdoc fails on objs that use property for __doc__
Bugs item #1367183, was opened at 2005-11-26 13:42 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367183&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Drew Perttula (drewp) >Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getdoc fails on objs that use property for __doc__ Initial Comment: inspect.getdoc has these lines: if not isinstance(doc, types.StringTypes): return None which interfere with the case where __doc__ is some other thing that has a good __str__. I wanted to make a lazy __doc__ that did an expensive lookup of some external documentation only when it was str()'d, but since doc displayers often (correctly) use inspect.getdoc, they were getting None. I think the intention of the test in getdoc() is to avoid trying string operations on a __doc__ that is None. I think that a more lenient version would allow me to do my fancy docstrings but still solve the '__doc__ is None' problem. Please consider the following patch: if doc is None: return None doc = str(doc) -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-20 00:04 Message: Logged In: YES user_id=33168 That code doesn't work if doc is unicode. I'm not sure how to achieve what you want. -- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-20 00:21 Message: Logged In: YES user_id=1188172 I don't know. Neal, do you have an opinion about property docstrings? -- Comment By: Collin Winter (collinwinter) Date: 2006-02-01 03:35 Message: Logged In: YES user_id=1344176 It's not a good idea to use properties for __doc__: """ >>> class Foo(object): ...def _get(self): ...return 'the docstring' ...__doc__ = property(_get) ... >>> print Foo().__doc__ the docstring >>> print Foo.__doc__ >>> """ In this light, I don't view inspect.getdoc's lack of support for __doc__-as-property as a bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367183&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1227955 ] shelve/bsddb crash on db close
Bugs item #1227955, was opened at 2005-06-26 16:38 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227955&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Scott (ses4j) Assigned to: Neal Norwitz (nnorwitz) Summary: shelve/bsddb crash on db close Initial Comment: I have a 300 meg bsddb/hash db created and accessed by shelve. No problems when running python only. But I started accessing the code that opens it via a windows DLL, opening and closing the DB on PROCESS_ATTACH and DETACH. All of a sudden, it would crash in the bsddb module on closing/del'ing the db. Found a workaround by opening the db with shelve.BsddbShelf(..) instead of shelve.open(..) - then it closed fine when the DLL unloaded, no crash. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-20 00:05 Message: Logged In: YES user_id=33168 Assuming this is fixed since there was no response. Closing. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 22:12 Message: Logged In: YES user_id=33168 If we don't hear back within a month, we should close this as probably fixed by the patch that was checked in. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 00:03 Message: Logged In: YES user_id=33168 Perhaps this is related to bug 1413192? Could you try the patch there and see if it fixes this problem? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227955&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1115379 ] Built-in compile function with PEP 0263 encoding bug
Bugs item #1115379, was opened at 2005-02-03 05:11 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Christoph Zwerschke (cito) >Assigned to: Martin v. Löwis (loewis) Summary: Built-in compile function with PEP 0263 encoding bug Initial Comment: a = 'print "Hello, World"' u = '# -*- coding: utf-8 -*-\n' + a print compile(a, '', 'exec') # ok print compile(u, '', 'exec') # ok print compile(unicode(a), '', 'exec') # ok print compile(unicode(u), '', 'exec') # error # The last line gives a SystemError. # Think this is a bug. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-20 00:28 Message: Logged In: YES user_id=33168 Martin, the attached patches (2.4 and 2.5) fix the problem. However, it seems that the patches would violate the PEP according to one of your notes. I'm not sure about all the details, but ISTM based on your comment that if (flags && flags->cf_flags & PyCF_SOURCE_IS_UTF8) and (TYPE(n) == encoding_decl) this is an error that should be returned? I would like to get this fixed for 2.4.3, so we need to move fast for it. 2.5 can wait and is trivial to fix once we know what this is supposed to do. -- Comment By: Georg Brandl (gbrandl) Date: 2006-02-20 13:37 Message: Logged In: YES user_id=849994 This even aborts the interpreter in 2.5 HEAD with a failing assertion. -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-27 22:48 Message: Logged In: YES user_id=21627 If you load the files manually, why is it that you want to decode them to Unicode before compile()ing them? Couldn't you just pass the bytes you read from the file to compile()? -- Comment By: Vágvölgyi Attila (wigy) Date: 2005-09-27 21:29 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the beginning of the file before I can give it to the compile() function. What special advantage comes from the fact that the compiler does not simply ignore encoding declaration nodes from unicode objects? Does this error message catch some possible errors or does it make the compiler code simpler? -- Comment By: Vágvölgyi Attila (wigy) Date: 2005-09-27 21:20 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the beginning of the file before I can give it to the compile() function. What special advantage comes from the fact that the compiler does not simply ignore encoding declaration nodes from unicode objects? Does this error message catch some possible errors or does it make the compiler code simpler? -- Comment By: Martin v. Löwis (loewis) Date: 2005-02-09 16:37 Message: Logged In: YES user_id=21627 There is a bug somewhere, certainly. However, I believe it is in PEP 263, which should point out that unicode strings in compile are only legal if they do *not* contain an encoding declaration, as such strings are implicitly encoded as UTF-8. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1115379 ] Built-in compile function with PEP 0263 encoding bug
Bugs item #1115379, was opened at 2005-02-03 14:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Christoph Zwerschke (cito) Assigned to: Martin v. Löwis (loewis) Summary: Built-in compile function with PEP 0263 encoding bug Initial Comment: a = 'print "Hello, World"' u = '# -*- coding: utf-8 -*-\n' + a print compile(a, '', 'exec') # ok print compile(u, '', 'exec') # ok print compile(unicode(a), '', 'exec') # ok print compile(unicode(u), '', 'exec') # error # The last line gives a SystemError. # Think this is a bug. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-03-20 10:03 Message: Logged In: YES user_id=21627 I still wonder why anybody would want to do that, so I don't see it as a big problem that it gives an error in 2.4: it *should* give an error, although not the one it currently gives. It seems that wigy would expect that the encoding declaration is ignored, whereas you (nnorwitz) are suggesting that the UTF-8 default should be ignored. In the face of ambiguity, refuse the temptation to guess. So I still think it should give a SyntaxError instead. I'll attach an alternative patch. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-20 09:28 Message: Logged In: YES user_id=33168 Martin, the attached patches (2.4 and 2.5) fix the problem. However, it seems that the patches would violate the PEP according to one of your notes. I'm not sure about all the details, but ISTM based on your comment that if (flags && flags->cf_flags & PyCF_SOURCE_IS_UTF8) and (TYPE(n) == encoding_decl) this is an error that should be returned? I would like to get this fixed for 2.4.3, so we need to move fast for it. 2.5 can wait and is trivial to fix once we know what this is supposed to do. -- Comment By: Georg Brandl (gbrandl) Date: 2006-02-20 22:37 Message: Logged In: YES user_id=849994 This even aborts the interpreter in 2.5 HEAD with a failing assertion. -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-28 07:48 Message: Logged In: YES user_id=21627 If you load the files manually, why is it that you want to decode them to Unicode before compile()ing them? Couldn't you just pass the bytes you read from the file to compile()? -- Comment By: Vágvölgyi Attila (wigy) Date: 2005-09-28 06:29 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the beginning of the file before I can give it to the compile() function. What special advantage comes from the fact that the compiler does not simply ignore encoding declaration nodes from unicode objects? Does this error message catch some possible errors or does it make the compiler code simpler? -- Comment By: Vágvölgyi Attila (wigy) Date: 2005-09-28 06:20 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the beginning of the file before I can give it to the compile() function. What special advantage comes from the fact that the compiler does not simply ignore encoding declaration nodes from unicode objects? Does this error message catch some possible errors or does it make the compiler code simpler? -- Comment By: Martin v. Löwis (loewis) Date: 2005-02-10 01:37 Message: Logged In: YES user_id=21627 There is a bug somewhere, certainly. However, I believe it is in PEP 263, which should point out that unicode strings in compile are only legal if they do *not* contain an encoding declaration, as such strings are implicitly encoded as UTF-8. -- You can respond by vi
[ python-Feature Requests-1454344 ] Make more out of 'as' : general ad-hoc right-assignment
Feature Requests item #1454344, was opened at 2006-03-20 10:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1454344&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make more out of 'as' : general ad-hoc right-assignment
Initial Comment:
"with EXPR as VAR" introduces 'as' as keyword.
Occupying a new 2-letter kw, Python could maybe make
more out of this:
* it was often asked for transitive assignments to
speed up the interrupted style of typing in Python
* yet transitive left-assignments = += *= ... would
indeed be an impact on pythonic discipline, create bad
readable syntax, which can easyly be confused with ==
etc inside of Expressions. It would be not intuitive,
with what value we are computing. Think e.g. of ugly
things like:
> a = ( 1+ (b.=2/x) )
Now trying a right-hand-assignment method using 'as'
everywhere:
> with open(x) as f:
>f.write(s)
> if re.search(x,s) as m:
>print m.group(1)
> elif re.search(y,s) as m:
>print m.group(1)
> while (x+1 as x) not in l:
>do()
> a = ( 1+ ( 2/x as b ) ), 2+b, 3+b
>
> print 'comment number', (id+1 as id)
* I cannot see any uglyness in this kind of
right-hand-assignment. Its intuitive 'english', speeds
up typing tremendously, the computed thing on left side
is still that, what is in the focus of reading.
And maybe most important: it supports a natural
evolutionary style of thinking: First you think about
what you want compute in expressions, then you can
store aside usefull stuff to somewhere happily.
* 'as'-evolution with extra operator is not too
tempting and clearly separated from the main =
'planning' doctrin
* The operator priority of 'as' right-assignments
should be higher than that of left-assignments and be
next before brackets and commas. Execution order from
left to right - that resolves as expected :
> a += b as c
> l=[ 1 as one, one+1 as two, {key as mykey:3 as three} ]
> d=dict(var1=pi/2 as pi_2, )
The later 'as' would of course set pi_2 in caller's
context.
A transitive 'as' would be more important than having
'is' for the same as '=='. In fact, if "with .. as .."
is possible, but "if .. as .." not, this would appear
as broken syntax design to python newcomers.
Robert
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1454344&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1454364 ] Python space syntax & pythonic long lambda's
Feature Requests item #1454364, was opened at 2006-03-20 10:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1454364&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: Python space syntax & pythonic long lambda's Initial Comment: (see also c.l.p http://groups.google.de/group/comp.lang.python/browse_frm/thread/fc2df1723f499eb7/f7e9b2ac5a6b5f16 ) After I had often nasty bugs because of mixup with the global statement, my home made "_global=sys.modules[__name__]" method (see also c.l.p http://groups.google.de/group/comp.lang.python/browse_frm/thread/fc2df1723f499eb7/f7e9b2ac5a6b5f16 ) prevents effectively such errors from my experience. And code is better readable. Despite maybe similar suggestions have already been disregard, I put for discussion this version of (compatible) extended space syntax for: better atomic python expressions, improved readability, new key capabilites for inter-frame/"block" access and functional programming support: See attached .txt document. Robert -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1454364&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1449496 ] Python should use 3GB Address Space on Windows
Feature Requests item #1449496, was opened at 2006-03-14 12:04 Message generated for change (Comment added) made by gfe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1449496&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Gfeller (gfe) Assigned to: Nobody/Anonymous (nobody) Summary: Python should use 3GB Address Space on Windows Initial Comment: Python runs fine using a 3GB address space on 32bit Windows. To take advantage of this feature, Python should be linked using the /LARGEADDRESSAWARE flag of the linker. For details, please refer to: http://msdn.microsoft.com/library/en- us/memory/base/4gt_ram_tuning.asp As most Windows users just use pre-built executables, this would be a worthwhile change. Best regards, Martin Gfeller -- >Comment By: Martin Gfeller (gfe) Date: 2006-03-20 13:08 Message: Logged In: YES user_id=884167 Tim, the /LARGEADDRESSAWARE flag just specifies whether python.exe is enabled for #GB addresses, i.e. doesn't use dubious pointer manipulations that make it fail with a 3GB address space. It does not cause Windows to provide the 3GB address space, nor to reduce cache and pool size - that is controlled separately by the /3GB boot switch (and various registry settings for finer control of cache and pool sizes). In other words, it is an enabling declaration, not a control parameter. Josiah, I don't compile on Windows, hence cannot provide a patch. What I did is applying the flag to the executable by using editbin.exe. Brgds, Martin -- Comment By: Tim Peters (tim_one) Date: 2006-03-18 03:38 Message: Logged In: YES user_id=31435 MS also says "However, the file cache, paged pool, and non-paged pool are smaller, which can adversely affect applications with heavy networking or I/O", so the rationale for making this change is clear as mud. That is, it's not a pure win: some apps win at the expense of others. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-03-18 01:38 Message: Logged In: YES user_id=341410 Microsoft claims that the switch does not negatively affect users on systems without large amounts of memory, and the extra gig of memory on platforms which could use it would be nice. Can you offer a patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1449496&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1453341 ] sys.setatomicexecution - for critical sections
Feature Requests item #1453341, was opened at 2006-03-18 20:52 Message generated for change (Comment added) made by gfe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: sys.setatomicexecution - for critical sections Initial Comment: In order to maintain threaded code uncomplicated (VHL) and in order to avoid massive use of locks, when introducing few critical non-atomic sections, it should be possible to put out that practical hammer .. try: last_ci=sys.setcheckinterval(sys.maxint) critical_function() # now runs atomically finally: sys.setcheckinterval(last_ci) #(sys.setcheckinterval assumed to return the last value) ..by an official function/class (in sys or thread): Maybe: == atomic = sys.setatomicexecution(mode) try: print "Executing critical section" finally: sys.setatomicexecution(atomic) there should be different modes/levels for blocking : * 0=None * 1=block only python execution in other threads * 2=block signals * 4/5/7/15=block threads at OS level (if OS supports) * 8=(reserved: block future sub-/stackless switching inside current thread..) see: http://groups.google.de/group/comp.lang.python/browse_frm/thread/bf5461507803975e/3bd7dfa9422a1200 compare: http://www.stackless.com/wiki/Tasklets#critical-sections --- Also Python could define officially its time atoms beyond CPU atoms in the docs (That also defines the VHL usability of the language). Thus thinks like single-element changes ... obj.var=x , d[key]=x , l.append(x) .pop() should be guaranteed to work atomic/correct FOR EVER. l[slice], d.keys() .items(), .. questionable? If not guaranteed for the future, offer duplicates for speed critical key building blocks like: l.slice_atomic(slice), d.keys_atomic() ,... in order to make code compatible for the future. --- Extra fun for blowing up python libs for poeple who don't want to learn that try..finally all the time: copy/deepcopy/dump maybe could be enriched by copy_atomic , deepcopy_atomic, dump_atomic - or just RuntimeError tolerant versions, deepcopy_save (no use of .iterxxx) -- Comment By: Martin Gfeller (gfe) Date: 2006-03-20 13:17 Message: Logged In: YES user_id=884167 - sys.setcheckinterval(sys.maxint) does not prevent thread switching when doing IO, does it? There is no way that I know of to prevent thread switching in this situation. - When calling back into Python from C Code, there is no way to tell Python not to relinquish the GIL; such an option could be useful for some C code, because the GIL provides a "global critical section". Martin -- Comment By: kxroberto (kxroberto) Date: 2006-03-18 22:54 Message: Logged In: YES user_id=972995 or: >>> atomic = sys.acquireatomicexecution(mode) >>> try: ... print 'critical section' ... finally: ... atomic.release() >>> with sys.acquireatomicexecution(mode): ... print 'critical section' -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1453341 ] sys.setatomicexecution - for critical sections
Feature Requests item #1453341, was opened at 2006-03-18 20:52 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: sys.setatomicexecution - for critical sections Initial Comment: In order to maintain threaded code uncomplicated (VHL) and in order to avoid massive use of locks, when introducing few critical non-atomic sections, it should be possible to put out that practical hammer .. try: last_ci=sys.setcheckinterval(sys.maxint) critical_function() # now runs atomically finally: sys.setcheckinterval(last_ci) #(sys.setcheckinterval assumed to return the last value) ..by an official function/class (in sys or thread): Maybe: == atomic = sys.setatomicexecution(mode) try: print "Executing critical section" finally: sys.setatomicexecution(atomic) there should be different modes/levels for blocking : * 0=None * 1=block only python execution in other threads * 2=block signals * 4/5/7/15=block threads at OS level (if OS supports) * 8=(reserved: block future sub-/stackless switching inside current thread..) see: http://groups.google.de/group/comp.lang.python/browse_frm/thread/bf5461507803975e/3bd7dfa9422a1200 compare: http://www.stackless.com/wiki/Tasklets#critical-sections --- Also Python could define officially its time atoms beyond CPU atoms in the docs (That also defines the VHL usability of the language). Thus thinks like single-element changes ... obj.var=x , d[key]=x , l.append(x) .pop() should be guaranteed to work atomic/correct FOR EVER. l[slice], d.keys() .items(), .. questionable? If not guaranteed for the future, offer duplicates for speed critical key building blocks like: l.slice_atomic(slice), d.keys_atomic() ,... in order to make code compatible for the future. --- Extra fun for blowing up python libs for poeple who don't want to learn that try..finally all the time: copy/deepcopy/dump maybe could be enriched by copy_atomic , deepcopy_atomic, dump_atomic - or just RuntimeError tolerant versions, deepcopy_save (no use of .iterxxx) -- >Comment By: kxroberto (kxroberto) Date: 2006-03-20 16:24 Message: Logged In: YES user_id=972995 thus the GIL could simply have a harder state 2 : "locked hard for PyEval_AcquireThread/PyEval_AcquireLock/.." ? Only PyEval_RestoreThread gets the lock again after PyEval_SaveThread. Robert -- Comment By: Martin Gfeller (gfe) Date: 2006-03-20 13:17 Message: Logged In: YES user_id=884167 - sys.setcheckinterval(sys.maxint) does not prevent thread switching when doing IO, does it? There is no way that I know of to prevent thread switching in this situation. - When calling back into Python from C Code, there is no way to tell Python not to relinquish the GIL; such an option could be useful for some C code, because the GIL provides a "global critical section". Martin -- Comment By: kxroberto (kxroberto) Date: 2006-03-18 22:54 Message: Logged In: YES user_id=972995 or: >>> atomic = sys.acquireatomicexecution(mode) >>> try: ... print 'critical section' ... finally: ... atomic.release() >>> with sys.acquireatomicexecution(mode): ... print 'critical section' -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1453341 ] sys.setatomicexecution - for critical sections
Feature Requests item #1453341, was opened at 2006-03-18 20:52 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: sys.setatomicexecution - for critical sections Initial Comment: In order to maintain threaded code uncomplicated (VHL) and in order to avoid massive use of locks, when introducing few critical non-atomic sections, it should be possible to put out that practical hammer .. try: last_ci=sys.setcheckinterval(sys.maxint) critical_function() # now runs atomically finally: sys.setcheckinterval(last_ci) #(sys.setcheckinterval assumed to return the last value) ..by an official function/class (in sys or thread): Maybe: == atomic = sys.setatomicexecution(mode) try: print "Executing critical section" finally: sys.setatomicexecution(atomic) there should be different modes/levels for blocking : * 0=None * 1=block only python execution in other threads * 2=block signals * 4/5/7/15=block threads at OS level (if OS supports) * 8=(reserved: block future sub-/stackless switching inside current thread..) see: http://groups.google.de/group/comp.lang.python/browse_frm/thread/bf5461507803975e/3bd7dfa9422a1200 compare: http://www.stackless.com/wiki/Tasklets#critical-sections --- Also Python could define officially its time atoms beyond CPU atoms in the docs (That also defines the VHL usability of the language). Thus thinks like single-element changes ... obj.var=x , d[key]=x , l.append(x) .pop() should be guaranteed to work atomic/correct FOR EVER. l[slice], d.keys() .items(), .. questionable? If not guaranteed for the future, offer duplicates for speed critical key building blocks like: l.slice_atomic(slice), d.keys_atomic() ,... in order to make code compatible for the future. --- Extra fun for blowing up python libs for poeple who don't want to learn that try..finally all the time: copy/deepcopy/dump maybe could be enriched by copy_atomic , deepcopy_atomic, dump_atomic - or just RuntimeError tolerant versions, deepcopy_save (no use of .iterxxx) -- >Comment By: kxroberto (kxroberto) Date: 2006-03-20 16:28 Message: Logged In: YES user_id=972995 ... only PyEval_RestoreThread with the harder execution level in its tstate -- Comment By: kxroberto (kxroberto) Date: 2006-03-20 16:24 Message: Logged In: YES user_id=972995 thus the GIL could simply have a harder state 2 : "locked hard for PyEval_AcquireThread/PyEval_AcquireLock/.." ? Only PyEval_RestoreThread gets the lock again after PyEval_SaveThread. Robert -- Comment By: Martin Gfeller (gfe) Date: 2006-03-20 13:17 Message: Logged In: YES user_id=884167 - sys.setcheckinterval(sys.maxint) does not prevent thread switching when doing IO, does it? There is no way that I know of to prevent thread switching in this situation. - When calling back into Python from C Code, there is no way to tell Python not to relinquish the GIL; such an option could be useful for some C code, because the GIL provides a "global critical section". Martin -- Comment By: kxroberto (kxroberto) Date: 2006-03-18 22:54 Message: Logged In: YES user_id=972995 or: >>> atomic = sys.acquireatomicexecution(mode) >>> try: ... print 'critical section' ... finally: ... atomic.release() >>> with sys.acquireatomicexecution(mode): ... print 'critical section' -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1436428 ] urllib has trouble with Windows filenames
Bugs item #1436428, was opened at 2006-02-22 06:03 Message generated for change (Comment added) made by bobince You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436428&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Donovan Eastman (dpeastman) Assigned to: Nobody/Anonymous (nobody) Summary: urllib has trouble with Windows filenames Initial Comment: When you pass urllib the name of a local file including a Windows drive letter (e.g. 'C:\dir\My File.txt') URLopener.open() incorrectly interprets the drive letter as the scheme of a URL. Of course, given that there is no scheme 'C', this fails. I have solved this in my own code by putting the following test before calling urllib.urlopen(): if url[1] == ':' and url[0].isalpha(): url = 'file:' + url Although this works fine in my particular case, it seems like urllib should just simply "do the right thing" without having to worry about it. Therefore I propose that urllib should automatically assume that any URL that begins with a single alpha followed by a colon is a local file. The only potential downside would be that it would preclude the use of single letter scheme names. I did a little research on this. RFC 3986 suggests, but does not explicitly state that scheme names must be more than one character. (http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#scheme) . That said, there are no currently recognized single letter scheme names (http://www.iana.org/assignments/uri-schemes.html) and it seems very unlikely that there every would be. I would gladly write the code for this myself -- but I suspect that it would take someone longer to review and integrate my changes than it would to just write the code. Thanks, Donovan -- Comment By: Andrew Clover (bobince) Date: 2006-03-20 17:41 Message: Logged In: YES user_id=311085 Filepaths aren't URIs and attempting to hide the difference in the backend is doomed to fail (as it did for SAX). Throw filenames with colons in, network paths, Mac paths and RISC OS paths into the mix, and you've got a situation where it is all but impossible to handle correctly. In any case, the docs *don't* say you can pass in a filepath: If the URL does not have a scheme identifier, or if it has file: as its scheme identifier, this opens a local file This means the string you pass in is unequivocally a URL *not* a pathname... just that you can leave the scheme prefix off for file: URLs. Effectively this is a relative URL. r'C:\spam' is *not* a valid way to refer to a local file using a relative URL. Pass it through pathname2url and you'll get '///C|/spam', which is okay; 'C|/spam' and '/C|span' will also work. Even on Unix, a filepath won't always work when passed to urlopen. Filenames can have percent signs in, which have to be encoded in URLs, for example. Always use pathname2url or you're going to trip up. (Suggest setting status INVALID, possible clarification to docs to warn against passing a filepath to urlopen?) -- Comment By: Donovan Eastman (dpeastman) Date: 2006-03-14 02:32 Message: Logged In: YES user_id=757799 OK - Here's my suggested fix: This can be fixed with a single if statement (and a comment to explain it to confused unix programmers). In splittype(), right after the line that reads: scheme = match.group(1) add the following: #ignore single char schemes to avoid confusion with win32 drive letters if len(scheme) > 1: ...and indent the next line. Alternatively, the if statement could read: if len(scheme) > 1 or sys.platform != 'win32': ...which would allow single letter scheme names on non-Windows systems. I would argue that it is better to be consistent and have it work the same way on all OS's. -- Comment By: Donovan Eastman (dpeastman) Date: 2006-03-14 01:56 Message: Logged In: YES user_id=757799 Reasons why urllib should open local files: 1) This allows you to write code that handles local files and Internet files equally well -- without having to do any special magic of your own. 2) The docs all say that it should. I believe this would work just fine under Unix. In URLopener.open() it looks for the protocol prefix and if it can't find one, it assumes that it is a local file. The problem on Windows is that you have these pesky drive letters. The form 'C:\location' ends up looking a lot like the form 'http://location'. Therefore it looks for a protocol called 'c' -- which obviously isn't going to work. -- Comment By: Koen van de Sa
[ python-Feature Requests-1437699 ] allow unicode arguments for robotparser.can_fetch
Feature Requests item #1437699, was opened at 2006-02-23 22:07
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1437699&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: osvenskan (osvenskan)
>Assigned to: Skip Montanaro (montanaro)
Summary: allow unicode arguments for robotparser.can_fetch
Initial Comment:
One-line summary: If the robotparser module encounters
a robots.txt file that contains non-ASCII characters
AND I pass a Unicode user agent string to can_fetch(),
that function crashes with a TypeError under Python
2.4. Under Python 2.3, the error is a UnicodeDecodeError.
More detail:
When one calls can_fetch(MyUserAgent, url), the
robotparser module compares the UserAgent to each user
agent described in the robots.txt file. If
isinstance(MyUserAgent, str) == True then the
comparison does not raise an error regardless of the
contents of robots.txt. However, if
isinstance(MyUserAgent, unicode) == True, then Python
implicitly tries to convert the contents of the
robots.txt file to Unicode before comparing it to
MyUserAgent. By default, Python assumes a US-ASCII
encoding when converting, so if the contents of
robots.txt aren't ASCII, the conversion fails. In other
words, this works:
MyRobotParser.can_fetch('foobot', url)
but this fails:
MyRobotParser.can_fetch(u'foobot', url)
I recreated this with Python 2.4.1 on FreeBSD 6 and
Python 2.3 under Darwin/OS X. I'll attach examples from
both. The URLs that I use in the attachments are from
my Web site and will remain live. They reference
robots.txt files which contain an umlaut-ed 'a' (0xe4
in iso-8859-1). They're served up using a special
.htaccess file that adds a Content-Type header which
correctly identifies the encoding used for each file.
Here's the contents of the .htaccess file:
AddCharset iso-8859-1 .iso8859-1
AddCharset utf-8 .utf8
A suggested solution:
AFAICT, the construction of robots.txt is still defined
by "a consensus on 30 June 1994 on the robots mailing
list" [http://www.robotstxt.org/wc/norobots.html] and a
1996 draft proposal
[http://www.robotstxt.org/wc/norobots-rfc.html] that
has never evolved into a formal standard. Neither of
these mention character sets or encodings which is no
surprise considering that they date back to the days
when the Internet was poor but happy and we considered
even ASCII a luxury and we were grateful to have it.
("ASCII? We used to dream of having ASCII. We only had
one bit, and it was a zero. We lived in a shoebox in
the middle of the road..." etc.) A backwards-compatible
yet forward-looking solution would be to have the
robotparser module respect the Content-Type header sent
with robots.txt. If no such header is present,
robotparser should try to decode it using iso-8859-1
per section 3.7.1 of the HTTP 1.1 spec
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1)
which says, 'When no explicit charset parameter is
provided by the sender, media subtypes of the "text"
type are defined to have a default charset value of
"ISO-8859-1" when received via HTTP. Data in character
sets other than "ISO-8859-1" or its subsets MUST be
labeled with an appropriate charset value.' Section
3.6.1 of the HTTP 1.0 spec says the same. Since
ISO-8859-1 is a superset of US-ASCII, robots.txt files
that are pure ASCII won't be affected by the change.
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-20 20:33
Message:
Logged In: YES
user_id=38388
Reassigning to Skip: I don't use robotparser.
Skip, perhaps you can have a look ? (Didn't you write the
robotparser ?)
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 11:17
Message:
Logged In: YES
user_id=849994
Turning into a Feature Request.
--
Comment By: osvenskan (osvenskan)
Date: 2006-03-07 17:32
Message:
Logged In: YES
user_id=1119995
Thanks for looking at this. I have some followup comments.
The list at robotstxt.org is many years stale (note that
Google's bot is present only as Backrub which was still a
server at Stanford at the time:
http://www.robotstxt.org/wc/active/html/backrub.html) but
nevertheless AFAICT it is the most current bot list on the
Web. If you look carefully, the list *does* contain a
non-ASCII entry (#76 --easy to miss in that long list). That
Finnish bot is gone but it has left a legacy in the form of
many robots.txt files that were created by automated tools
based on the robotstxt.org list. Google helps us here:
http://www.google.com/search?q=allintext%3AH%C3%A4m%C3%A4h%C3%A4kki+disallow+filetype%3At
[ python-Bugs-1454855 ] Explanation of pow() in lib
Bugs item #1454855, was opened at 2006-03-20 20:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454855&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: Explanation of pow() in lib Initial Comment: The Python Lib Reference explains the pow() function in section 2.1 like that: >>> pow(x, y[, z]) Return x to the power y; if z is present, return x to the power y, modulo z (computed more efficiently than pow(x, y) % z). The arguments must have numeric types. With mixed operand types, the coercion rules for binary arithmetic operators apply. For int and long int operands, the result has the same type as the operands (after coercion) unless the second argument is negative; in that case, all arguments are converted to float and a float result is delivered. For example, 10**2 returns 100, but 10**-2 returns 0.01. <<< The problem is here that the notation 10**2 is used in the example without prior explanation that it is equivalent to pow(10,2). A newbie reading the docs in linear order may not know this here (many other languages write x^y instead of x**y). The notation x**y is only introduced later in section 2.3.4. I recommend adding a short remark to this paragraph explaining that instead of writing pow(x,y) you can also write x**y. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454855&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1454855 ] Explanation of pow() in lib
Bugs item #1454855, was opened at 2006-03-20 20:54 Message generated for change (Settings changed) made by cito You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454855&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Not a Bug Status: Open Resolution: None >Priority: 2 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: Explanation of pow() in lib Initial Comment: The Python Lib Reference explains the pow() function in section 2.1 like that: >>> pow(x, y[, z]) Return x to the power y; if z is present, return x to the power y, modulo z (computed more efficiently than pow(x, y) % z). The arguments must have numeric types. With mixed operand types, the coercion rules for binary arithmetic operators apply. For int and long int operands, the result has the same type as the operands (after coercion) unless the second argument is negative; in that case, all arguments are converted to float and a float result is delivered. For example, 10**2 returns 100, but 10**-2 returns 0.01. <<< The problem is here that the notation 10**2 is used in the example without prior explanation that it is equivalent to pow(10,2). A newbie reading the docs in linear order may not know this here (many other languages write x^y instead of x**y). The notation x**y is only introduced later in section 2.3.4. I recommend adding a short remark to this paragraph explaining that instead of writing pow(x,y) you can also write x**y. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454855&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1454855 ] Explanation of pow() in lib
Bugs item #1454855, was opened at 2006-03-20 14:54 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454855&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Not a Bug >Status: Closed >Resolution: Works For Me Priority: 2 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: Explanation of pow() in lib Initial Comment: The Python Lib Reference explains the pow() function in section 2.1 like that: >>> pow(x, y[, z]) Return x to the power y; if z is present, return x to the power y, modulo z (computed more efficiently than pow(x, y) % z). The arguments must have numeric types. With mixed operand types, the coercion rules for binary arithmetic operators apply. For int and long int operands, the result has the same type as the operands (after coercion) unless the second argument is negative; in that case, all arguments are converted to float and a float result is delivered. For example, 10**2 returns 100, but 10**-2 returns 0.01. <<< The problem is here that the notation 10**2 is used in the example without prior explanation that it is equivalent to pow(10,2). A newbie reading the docs in linear order may not know this here (many other languages write x^y instead of x**y). The notation x**y is only introduced later in section 2.3.4. I recommend adding a short remark to this paragraph explaining that instead of writing pow(x,y) you can also write x**y. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-20 15:07 Message: Logged In: YES user_id=80475 The Lib Reference is like an encylopaedia; it does not purport to avoid forward references and be read linearly start to finish. Also, in this case the meaning is 100% clear from the context. IOW, given a discussion about x raised to the y power and an expression "10**2 returns 100, but 10**-2 returns 0.01", the meaning of the operator is self-evident. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454855&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1115379 ] Built-in compile function with PEP 0263 encoding bug
Bugs item #1115379, was opened at 2005-02-03 05:11 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Christoph Zwerschke (cito) Assigned to: Martin v. Löwis (loewis) Summary: Built-in compile function with PEP 0263 encoding bug Initial Comment: a = 'print "Hello, World"' u = '# -*- coding: utf-8 -*-\n' + a print compile(a, '', 'exec') # ok print compile(u, '', 'exec') # ok print compile(unicode(a), '', 'exec') # ok print compile(unicode(u), '', 'exec') # error # The last line gives a SystemError. # Think this is a bug. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-20 13:14 Message: Logged In: YES user_id=33168 Actually, I don't much care about the answer as long as it isn't a core dump/assert or a SystemError. I'm fine with a syntax error. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-20 01:03 Message: Logged In: YES user_id=21627 I still wonder why anybody would want to do that, so I don't see it as a big problem that it gives an error in 2.4: it *should* give an error, although not the one it currently gives. It seems that wigy would expect that the encoding declaration is ignored, whereas you (nnorwitz) are suggesting that the UTF-8 default should be ignored. In the face of ambiguity, refuse the temptation to guess. So I still think it should give a SyntaxError instead. I'll attach an alternative patch. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-20 00:28 Message: Logged In: YES user_id=33168 Martin, the attached patches (2.4 and 2.5) fix the problem. However, it seems that the patches would violate the PEP according to one of your notes. I'm not sure about all the details, but ISTM based on your comment that if (flags && flags->cf_flags & PyCF_SOURCE_IS_UTF8) and (TYPE(n) == encoding_decl) this is an error that should be returned? I would like to get this fixed for 2.4.3, so we need to move fast for it. 2.5 can wait and is trivial to fix once we know what this is supposed to do. -- Comment By: Georg Brandl (gbrandl) Date: 2006-02-20 13:37 Message: Logged In: YES user_id=849994 This even aborts the interpreter in 2.5 HEAD with a failing assertion. -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-27 22:48 Message: Logged In: YES user_id=21627 If you load the files manually, why is it that you want to decode them to Unicode before compile()ing them? Couldn't you just pass the bytes you read from the file to compile()? -- Comment By: Vágvölgyi Attila (wigy) Date: 2005-09-27 21:29 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the beginning of the file before I can give it to the compile() function. What special advantage comes from the fact that the compiler does not simply ignore encoding declaration nodes from unicode objects? Does this error message catch some possible errors or does it make the compiler code simpler? -- Comment By: Vágvölgyi Attila (wigy) Date: 2005-09-27 21:20 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the beginning of the file before I can give it to the compile() function. What special advantage comes from the fact that the compiler does not simply ignore encoding declaration nodes from unicode objects? Does this error message catch some possible errors or does it make the compiler code simpler? -- Comment By: Martin v. Löwis (loewis) Date: 2005-02-09 16:37 Message: Logged In: YES user_id=21627 There is a bug somewhere, cer
[ python-Bugs-1433877 ] string parameter to ioctl not null terminated, includes fix
Bugs item #1433877, was opened at 2006-02-17 23:29 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Quentin Barnes (qbarnes) Assigned to: Thomas Wouters (twouters) Summary: string parameter to ioctl not null terminated, includes fix Initial Comment: I ran across this problem in Python 2.3.3 and see it is still there in 2.4.2. When running the test_pty.py test case, I would get intermittant failures depending on how the test was invoked or the compiler flags used on Solaris. Trussing the interpreter while running the test revealed: ioctl(4, I_PUSH, "ptem\xff^T^F^H") Err#22 EINVAL There was garbage on the end of the string when it would fail. I tracked the problem back to fcntl_ioctl() in fcntlmodule.c. The string was not being NULL terminated, but relied on having zeroed gargage on the stack to work. I checked the source for 2.4.2 and noticed the same problem. Patch to fix the problem is attached. -- >Comment By: Thomas Wouters (twouters) Date: 2006-03-20 22:22 Message: Logged In: YES user_id=34209 Huh, I never even saw this patch, in spite of the high priority and it being assigned to me. We didn't discuss it at PyCon (at least, I wasn't party to the discussion) but I guess this patch doesn't really hurt, and does fix actual problems. I'm wary of fudging fcntl/ioctl too much; I'd _much_ rather try and come up with a decent interface for Py3k, with mutable bytestrings and all that, maybe some nice automatic argument-type-conversion or higher-level interface for common features (like advisory locks) -- and only keep 2.x's fcntl working as well as it does. -- Comment By: Guido van Rossum (gvanrossum) Date: 2006-02-20 21:52 Message: Logged In: YES user_id=6380 mwh: Sorry about the docstring gripe -- I read the fcntl() docstring which is right above the ioctl() implementation and never realized that this particular C module places the doc strings *after* the functions. (I think that's bad style but there it is.) I think the priority was set to 9 by Neal to get Thomas' attention. gbarnes: We'll decide this one at PyCon. -- Comment By: Quentin Barnes (qbarnes) Date: 2006-02-20 19:00 Message: Logged In: YES user_id=288734 I didn't write new code that causes this problem by calling ioctl with a string that needed to be null terminated. It was already in Python code itself. See Lib/pty.py for the code. I reworked the patch as discussed below and retested it. All built-in tests passed. I've attached it. I hae no idea of Python coding conventions or style. Hopefully I didn't violate them too badly. (This was weird. SF rejected the text above when I submitted it, but it took the patch file. The patch file shows up as "nobody". Resubmitting this text.) -- Comment By: Michael Hudson (mwh) Date: 2006-02-20 11:54 Message: Logged In: YES user_id=6656 Seeing as some of this is my code... Guido, the ioctl docstring *does* mention mutate_arg. I agree that the documentation should have been updated for 2.4 and 2.5... and the situation is a mess, yes, but one that I couldn't see a better way around when the feature was added (it was much discussed in the bug report at the time). It certainly never occurred to me that you might need/want to pass a NULL terminated string to ioctl. I don't think this is a priority 9 report. -- Comment By: Guido van Rossum (gvanrossum) Date: 2006-02-20 06:04 Message: Logged In: YES user_id=6380 Sorry for the confusion. I was in part responding to an off-line discussion I had with Neal Norwitz, to which you weren't a party. You can ignore my comments about safety and crashing. The difference in marshalling Python data to C data for ioctl(), compared to the many other places where (indeed) this problem has been solved before, is that almost everywhere else, we *know* what the data is supposed to mean. C has many more data types than Python, and the choice of how to convert a string, or an int, to C data depends on what is expected by the receiver of the C data. Unfortunately for ioctl we don't know the required C data type because it's defined by the kernel module that handles the particular ioctl opcode. Some of these (like the one you apparently ran into when porting the pty code to Solaris) require a null-terminated st
[ python-Bugs-1454912 ] import email fails
Bugs item #1454912, was opened at 2006-03-20 22:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454912&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Barry A. Warsaw (bwarsaw) Summary: import email fails Initial Comment: After Barry's merge of the email 4.0 package, importing email fails with the message that mime cannot be imported. The reason seems to be that email/mime should be added to LIBSUBDIRS in the top-level Makefile.pre.in. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454912&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1454855 ] Explanation of pow() in lib
Bugs item #1454855, was opened at 2006-03-20 20:54 Message generated for change (Comment added) made by cito You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454855&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Not a Bug Status: Closed Resolution: Works For Me Priority: 2 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: Explanation of pow() in lib Initial Comment: The Python Lib Reference explains the pow() function in section 2.1 like that: >>> pow(x, y[, z]) Return x to the power y; if z is present, return x to the power y, modulo z (computed more efficiently than pow(x, y) % z). The arguments must have numeric types. With mixed operand types, the coercion rules for binary arithmetic operators apply. For int and long int operands, the result has the same type as the operands (after coercion) unless the second argument is negative; in that case, all arguments are converted to float and a float result is delivered. For example, 10**2 returns 100, but 10**-2 returns 0.01. <<< The problem is here that the notation 10**2 is used in the example without prior explanation that it is equivalent to pow(10,2). A newbie reading the docs in linear order may not know this here (many other languages write x^y instead of x**y). The notation x**y is only introduced later in section 2.3.4. I recommend adding a short remark to this paragraph explaining that instead of writing pow(x,y) you can also write x**y. -- >Comment By: Christoph Zwerschke (cito) Date: 2006-03-20 23:23 Message: Logged In: YES user_id=193957 I'm not sure about that. You are thinking too much from an expert/insider point of view, not from a newbie/learner point of view. For newbies, this is not so clear. See for example: http://groups.google.com/group/comp.lang.python/browse_frm/thread/c82eb3c3a6068b7d Even if the reader understands what 10**2 is, it is still not clear at this place whether this is a Python expression or simply a mathematical notation, and whether pow(x,y) behaves exactly like x**y or not. I still think a short note like "Note that you can also write x**y as an abbreviation for pow(x,y)." makes all of this clear and may be a help or a hint for newbies and non-mathematicians. Your argument that the Lib reference is not meant to be read like a novel is true, but the introduction says explicitely that reading it as a novel *is* an option, and encourages people to read at least chapter 2 which is actually one of the core parts of the whole Python documentation. So I think many newbies will read the Tutorial (where the equivalence of x**y and pow(x,y) is not mentioned either) and then at least chapter 2 from the Lib reference. And even if you take it only as a reference and just read the explanation of pow() it may be a good reminder that pow(x,y) is actually the same as x**y. -- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-20 21:07 Message: Logged In: YES user_id=80475 The Lib Reference is like an encylopaedia; it does not purport to avoid forward references and be read linearly start to finish. Also, in this case the meaning is 100% clear from the context. IOW, given a discussion about x raised to the y power and an expression "10**2 returns 100, but 10**-2 returns 0.01", the meaning of the operator is self-evident. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454855&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1449496 ] Python should use 3GB Address Space on Windows
Feature Requests item #1449496, was opened at 2006-03-14 06:04 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1449496&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Gfeller (gfe) Assigned to: Nobody/Anonymous (nobody) Summary: Python should use 3GB Address Space on Windows Initial Comment: Python runs fine using a 3GB address space on 32bit Windows. To take advantage of this feature, Python should be linked using the /LARGEADDRESSAWARE flag of the linker. For details, please refer to: http://msdn.microsoft.com/library/en- us/memory/base/4gt_ram_tuning.asp As most Windows users just use pre-built executables, this would be a worthwhile change. Best regards, Martin Gfeller -- >Comment By: Tim Peters (tim_one) Date: 2006-03-20 19:54 Message: Logged In: YES user_id=31435 Thanks, Martin. Raymond Chen notes that some C code can fail when this is enabled: http://blogs.msdn.com/oldnewthing/archive/2004/08/12/213468.aspx I doubt that core Python's C has 2GB assumptions, but extension modules might. Provided that whoever cares enough to write the patch (sorry, I don't) points to that info (in the NEWS file would be good enough), this is fine by me. -- Comment By: Martin Gfeller (gfe) Date: 2006-03-20 07:08 Message: Logged In: YES user_id=884167 Tim, the /LARGEADDRESSAWARE flag just specifies whether python.exe is enabled for #GB addresses, i.e. doesn't use dubious pointer manipulations that make it fail with a 3GB address space. It does not cause Windows to provide the 3GB address space, nor to reduce cache and pool size - that is controlled separately by the /3GB boot switch (and various registry settings for finer control of cache and pool sizes). In other words, it is an enabling declaration, not a control parameter. Josiah, I don't compile on Windows, hence cannot provide a patch. What I did is applying the flag to the executable by using editbin.exe. Brgds, Martin -- Comment By: Tim Peters (tim_one) Date: 2006-03-17 21:38 Message: Logged In: YES user_id=31435 MS also says "However, the file cache, paged pool, and non-paged pool are smaller, which can adversely affect applications with heavy networking or I/O", so the rationale for making this change is clear as mud. That is, it's not a pure win: some apps win at the expense of others. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-03-17 19:38 Message: Logged In: YES user_id=341410 Microsoft claims that the switch does not negatively affect users on systems without large amounts of memory, and the extra gig of memory on platforms which could use it would be nice. Can you offer a patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1449496&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
