[issue5310] operator precedence table is wrong

[Georg Brandl]

Georg Brandl  added the comment:

Fixed in r69769.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3558] Operator precedence misdocumented

[Georg Brandl]

Georg Brandl  added the comment:

Fixed in r69769.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5314] http client error

[cober J]

New submission from cober J :

Try to use http to send multi-byte utf8 data.

File "E:\DEVELOP\python\lib\http\client.py", line 904, in _send_request
self.endheaders(body.encode('ascii'))
UnicodeEncodeError: 'ascii' codec can't encode character '\u7231' in 
position 119: ordinal not in range(128)


I modified the lib/http/client.py document, and fix this problem.

--
components: Library (Lib)
files: client.py
messages: 82465
nosy: cober
severity: normal
status: open
title: http client error
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file13136/client.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Pernici Mario]

Pernici Mario  added the comment:

The attached patch uses mul1 in long_mul in the version patched with
30bit_longdigit13+optimizations.patch

Comparison between these two patches on hp pavilion Q8200 2.33GHz

pybench  patch   new patch
SimpleIntegerArithmetic  89  85
other tests equal

pidigits_noprint 2000   998  947

--
nosy: +pernici
Added file: 
http://bugs.python.org/file13137/30bit_longdigit13+optimizations1.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5306] Python 3.1 won't compile under Visual Studio 2005

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

Ah, I just saw this.  Yes, looks like a missing file during porting.  
That should affect VS2008 as well.  Cheers!

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Mark Dickinson]

Mark Dickinson  added the comment:

> Before such a version gets committed, I'd like to see it on Rietveld
> again.

Sure.  My original plan was to get the structural changes in first, and 
then worry about optimizations.

But now I think the x_divrem fix has to be considered a prerequisite for 
the 30-bit digits patch.  So I'll clean up the x_divrem code, include it 
in the basic patch and upload to Rietveld.  The other optimization (to 
multiplication) is more optional, potentially more controversial (it 
adds 60 or so lines of extra code), and should wait until after the 
commit and get a separate issue and review.

The x_divrem work actually simplifies the code (whilst not altering the 
underlying algorithm), as well as speeding it up.  Still, it's changing 
a subtle core algorithm, so we need to be *very* sure that the new 
code's correct before it goes in.  In particular, I want to add some 
tests to test_long that exercise the rare corner cases in the algorithm 
(which only become rarer when 30-bit digits are used).

I also want to understand Gregory's problems with configure before 
committing anything.

None of this is going to happen before the weekend, I'm afraid.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

[Mark Dickinson]

Mark Dickinson  added the comment:

http://codereview.appspot.com/14105/diff/1/2
File Python/marshal.c (right):

http://codereview.appspot.com/14105/diff/1/2#newcode160
Line 160: w_long((long)(Py_SIZE(ob) > 0 ? l : -l), p);
On 2009/02/18 21:27:04, Martin v. Löwis wrote:
> Ok, so I'd waive this for this patch; please do create a separate
report.

Done.

http://bugs.python.org/issue5308

http://codereview.appspot.com/14105

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5312] errno not being set

[Georg Brandl]

Georg Brandl  added the comment:

The problem is in os.py. This patch fixes it:

Index: Lib/os.py
===
--- Lib/os.py   (Revision 69769)
+++ Lib/os.py   (Arbeitskopie)
@@ -372,8 +372,8 @@
 saved_exc = e
 saved_tb = tb
 if saved_exc:
-raise error(saved_exc).with_traceback(saved_tb)
-raise error(last_exc).with_traceback(tb)
+raise saved_exc.with_traceback(saved_tb)
+raise last_exc.with_traceback(tb)


I suspect there may be other instances of this problem (I guess 2to3
converted that).

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5287] logging package on IronPython

[Vinay Sajip]

Vinay Sajip  added the comment:

Fixes checked into trunk & py3k.

--
resolution: accepted -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5192] Update log message formatting.

[Vinay Sajip]

Changes by Vinay Sajip :


--
resolution: wont fix -> rejected

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5315] signal handler never gets called

[Péter Szabó]

New submission from Péter Szabó :

According to http://docs.python.org/dev/library/signal.html , if I set
up a signal handler in the main thread, and then have the signal
delivered to the process, then the signal handler will be called in the
main thread. The attached Python script I've written, however, doesn't
work that way: sometimes the signal is completely lost, and the signal
handler is not called.

Here is how it should work. The code has two threads: the main thread
and the subthread. There is also a signal handler installed. The main
thread is running select.select(), waiting for a filehandle to become
readable. Then the subthread sends a signal to the process. The signal
handler writes a byte to the pipe. The select wakes up raising
'Interrupted system call' because of the signal.

I'm running Ubuntu Hardy on x86_64. With Python 2.4.5 and Python 2.5.2,
sometimes the signal handler is not called, and the select continues
waiting indefinitely. This is what I get on stdout in Python 2.4.5:

main pid=8555
--- 0
A
B
S
T
U
handler arg1=10 arg2=
select got="(4, 'Interrupted system call')"
read str='W'
--- 1
A
B
S
T
U

This means that iteration 0 completed successfully: the signal handler
got called, and the select raised 'Interrupted system call'. However,
iteration 1 was stuck: the signal handler was never called, and the
select waits indefinitely.

The script seems to work in Python 2.4.3, but it hangs in iteration
about 6.

--
components: Interpreter Core, Library (Lib)
files: tsig.py
messages: 82472
nosy: pts
severity: normal
status: open
title: signal handler never gets called
type: behavior
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file13138/tsig.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue949667] file write() method and non-blocking mode.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

setblocking() doesn't exist in py3k either, so reopening. I agree it
would be useful to set files as non-blocking in a portableway.

--
nosy: +pitrou
priority: low -> normal
status: pending -> open
versions: +Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue949667] setblocking() method on file objects

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
title: file write() method and non-blocking mode. -> setblocking() method on 
file objects

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4565] Rewrite the IO stack in C

[Antoine Pitrou]

Antoine Pitrou  added the comment:

After "rewrite the rest of StringIO in C", there's "sanitize the
destructor behaviour of IOBase (if at all possible)".

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4565] Rewrite the IO stack in C

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Oh, and "what to do of the now unused pure Python implementations in io.py"?
Easiest would be to dump them, as they will probably get hopelessly out
of sync, but perhaps there's some genuine portability/educational
advantage to keep them?

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1578269] Add os.link() and os.symlink() support for Windows

[Jason R. Coombs]

Jason R. Coombs  added the comment:

I've implemented symlink() for Windows in jaraco.windows v1.0, just
uploaded to pypi (http://pypi.python.org/pypi/jaraco.windows/1.0).  It
creates symlinks, so only works in Windows 6 and later, but it's
available for those platforms.

Hopefully something like this can be included in future Python versions.

--
nosy: +jaraco

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5316] Buildbot failures in test_site

[Antoine Pitrou]

New submission from Antoine Pitrou :

Recently, some buildbot failures have started appearing on trunk and
py3k with the following error:

==
FAIL: test_s_option (test.test_site.HelperFunctionsTests)
--

Traceback (most recent call last):
  File
"/home/pybot/buildarea/3.x.klose-ubuntu-i386/build/Lib/test/test_site.py",
line 105, in test_s_option
self.assertEqual(rc, 1)
AssertionError: 0 != 1

make: *** [buildbottest] Error 1

--
components: Library (Lib), Tests
messages: 82477
nosy: pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: Buildbot failures in test_site
type: behavior
versions: Python 2.7, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4111] Add DTrace probes

[Joe Ranieri]

Changes by Joe Ranieri :


--
nosy: +sirg3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5313] multiprocessing.process using os.close(sys.stdin.fileno) instead of sys.stdin.close()

[Jesse Noller]

Changes by Jesse Noller :


--
assignee:  -> jnoller

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5317] URL given for IronPython in CPython documentation incorrect

[David Fugate]

New submission from David Fugate :

http://docs.python.org/reference/introduction.html#alternate-
implementations states that the IronPython project's website URL is 
http://workspaces.gotdotnet.com/ironpython.  This site has actually 
been dead for quite some time and our official project page is 
http://www.ironpython.com/ which we plan on revamping shortly.

Thanks,

Dave

--
assignee: georg.brandl
components: Documentation
messages: 82478
nosy: dfugate, georg.brandl
severity: normal
status: open
title: URL given for IronPython in CPython documentation incorrect
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5317] URL given for IronPython in CPython documentation incorrect

[Georg Brandl]

Georg Brandl  added the comment:

Thanks, fixed in r69776.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5318] strip, rstrip & lstrip bug

[alexlc]

New submission from alexlc :

Examples of bad behaviour:

>>> 'abacde'.lstrip('ab')
'cde'
>>> 'abaaacde'.lstrip('ab')
'cde'
>>> 'aabacde'.lstrip('aab')
'cde'
>>> 'abcede'.rstrip( 'de' )
'abc'
>>> 'abacdeaab'.strip('ab')
'cde'

Probably a few more similar to these will fail as well.

I have tested this with a fairly recent 2.5 (maybe 2.53 maybe 2.54), and
with 2.6.1. I have commented this to a friend and he recalls problems
similar to these with lstrip and rstrip a few years ago, so it might
have been an early 2.4 version or a late 2.3.

Thanks.

--
components: Library (Lib)
messages: 82480
nosy: alexlc
severity: normal
status: open
title: strip, rstrip & lstrip bug
type: behavior
versions: Python 2.5, Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5318] strip, rstrip & lstrip bug

[Ezio Melotti]

Ezio Melotti  added the comment:

This is not a bug:
str.strip([chars])
 ... The chars argument is not a prefix or suffix; rather, all
combinations of its values are stripped: ...

http://docs.python.org/library/stdtypes.html#str.strip

--
nosy: +ezio.melotti

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5319] I/O error during one-liner fails to return OS error status

[Mike Coleman]

New submission from Mike Coleman :

$ python2.5 -c 'print((1, 2, 3))' > /dev/full || echo error status
close failed: [Errno 28] No space left on device
$

The above sequence should also output 'error status' before the next
prompt.  That is, python should not be returning EXIT_SUCCESS in this
situation.

--
messages: 82482
nosy: mkc
severity: normal
status: open
title: I/O error during one-liner fails to return OS error status
type: behavior
versions: Python 2.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5318] strip, rstrip & lstrip bug

[alexlc]

alexlc  added the comment:

Oh, thanks for letting me know and sorry for the trouble.
I should had read the docs more carefully. I have actually been using for a
long while the strip methods as I had described in the bug report. I was so
completely convinced about this that I didn't even thought about checking
again the docs.
I have to fix my code but I am happy nonetheless as I was kind of 'losing my
faith' in python after finding this.

Regards,
Alejandro

2009/2/19 Ezio Melotti 

>
> Ezio Melotti  added the comment:
>
> This is not a bug:
> str.strip([chars])
>  ... The chars argument is not a prefix or suffix; rather, all
> combinations of its values are stripped: ...
>
> http://docs.python.org/library/stdtypes.html#str.strip
>
> --
> nosy: +ezio.melotti
>
> ___
> Python tracker 
> 
> ___
>

Added file: http://bugs.python.org/file13139/unnamed

___
Python tracker 

___Oh, thanks for letting me know and sorry for the trouble.I should had read 
the docs more carefully. I have actually been using for a long while the strip 
methods as I had described in the bug report. I was so completely convinced 
about this that I didn't even thought about checking again the docs.
I have to fix my code but I am happy nonetheless as I was kind of 'losing 
my faith' in python after finding 
this.Regards,Alejandro2009/2/19 Ezio Melotti rep...@bugs.python.org>

Ezio Melotti ezio.melo...@gmail.com> added the 
comment:

This is not a bug:
str.strip([chars])
 ... The chars argument is not a prefix or suffix; rather, all
combinations of its values are stripped: ...

http://docs.python.org/library/stdtypes.html#str.strip"; 
target="_blank">http://docs.python.org/library/stdtypes.html#str.strip

--
nosy: +ezio.melotti

___
Python tracker rep...@bugs.python.org>
http://bugs.python.org/issue5318>
___

___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5319] I/O error during one-liner fails to return OS error status

[Mike Coleman]

Mike Coleman  added the comment:

Oops, I should have used the old python print syntax.  Nonetheless, the
behavior is the same:

$ python2.5 -c 'print 1, 2, 3' > /dev/full || echo error status
close failed: [Errno 28] No space left on device
$

--
components: +Interpreter Core

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5320] I/O error during one-liner gives bad diagnostic (and fails to return OS error status)

[Mike Coleman]

New submission from Mike Coleman :

$ python2.6 -c 'print 1, 2, 3' > /dev/full || echo error status
close failed in file object destructor:
Error in sys.excepthook:

Original exception was:
$

It seems like something other than blank lines should be printed here.

--
components: Interpreter Core
messages: 82485
nosy: mkc
severity: normal
status: open
title: I/O error during one-liner gives bad diagnostic (and fails to return OS 
error status)
type: behavior
versions: Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5321] I/O error during one-liner gives no (!) diagnostic (and fails to return OS error status)

[Mike Coleman]

New submission from Mike Coleman :

$ python3.0 -c 'print((1, 2, 3))' > /dev/full || echo error status
$

This command gives no indication whatsoever that anything has gone
wrong.  Following this with strace demonstrates that the interpreter is
in fact ignoring these errors:

2589  write(1, "(1, 2, 3)\n"..., 10)= -1 ENOSPC (No space left on
device)
2589  rt_sigaction(SIGINT, {SIG_DFL}, {0x47aa49, [], SA_RESTORER,
0x7fd5aa9da080}, 8) = 0
2589  write(1, "(1, 2, 3)\n"..., 10)= -1 ENOSPC (No space left on
device)
2589  write(1, "(1, 2, 3)\n"..., 10)= -1 ENOSPC (No space left on
device)
2589  write(1, "(1, 2, 3)\n"..., 10)= -1 ENOSPC (No space left on
device)
2589  exit_group(0) = ?

--
components: Interpreter Core
messages: 82486
nosy: mkc
severity: normal
status: open
title: I/O error during one-liner gives no (!) diagnostic (and fails to return 
OS error status)
type: behavior
versions: Python 3.0

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5320] I/O error during one-liner gives bad diagnostic (and fails to return OS error status)

[Mike Coleman]

Mike Coleman  added the comment:

Also, as with the other python versions, notice that the error status is
EXIT_SUCCESS (which it should not be).

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5318] strip, rstrip & lstrip bug

[Daniel Diniz]

Daniel Diniz  added the comment:

Thanks, Ezio!

--
nosy: +ajaksu2
resolution:  -> invalid
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5306] Python 3.1 won't compile under Visual Studio 2005

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Could one of the Windows experts do the port? I can't properly resolve
the conflicts or test the changes here.

--
assignee: benjamin.peterson -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4565] Rewrite the IO stack in C

[Benjamin Peterson]

Benjamin Peterson  added the comment:

I think we should just drop the Python implementations. There's no point
in trying to keep two implementations around.

Besides, if we don't backport IO in C, we can maintain them in the trunk. :)

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5312] errno not being set

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
assignee:  -> benjamin.peterson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4565] Rewrite the IO stack in C

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

> Oh, and "what to do of the now unused pure Python implementations in
io.py"?  Easiest would be to dump them, as they will probably get
hopelessly out of sync, but perhaps there's some genuine
portability/educational advantage to keep them?

The test suite should be run against both implementations.  That way
tested behavior will always be the same for both.  And all of its
behavior is tested, right? ;)

The value in the Python implementation is manifold.  For example:

  * It eases testing of new features/techniques.  Rather than going
straight to the C version when someone has an idea for a feature, it can
be implemented and tried out in Python.  If it's cool, then the extra
effort of porting to C can be undertaken.
  * It helps other Python implementations immensely.  PyPy, IronPython,
and Jython are all going to have to provide this library eventually (one
supposes).  Forcing them each to re-implement it will mean it will be
that much longer before they support it.

--
nosy: +exarkun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2771] test issue

[Martin v. Löwis]

Martin v. Löwis  added the comment:

Does this still work?

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4565] Rewrite the IO stack in C

[Benjamin Peterson]

Benjamin Peterson  added the comment:

On Thu, Feb 19, 2009 at 1:57 PM, Jean-Paul Calderone
 wrote:
>
> Jean-Paul Calderone  added the comment:
>
>> Oh, and "what to do of the now unused pure Python implementations in
> io.py"?  Easiest would be to dump them, as they will probably get
> hopelessly out of sync, but perhaps there's some genuine
> portability/educational advantage to keep them?
>
> The test suite should be run against both implementations.  That way
> tested behavior will always be the same for both.  And all of its
> behavior is tested, right? ;)
>
> The value in the Python implementation is manifold.  For example:
>
>  * It eases testing of new features/techniques.  Rather than going
> straight to the C version when someone has an idea for a feature, it can
> be implemented and tried out in Python.  If it's cool, then the extra
> effort of porting to C can be undertaken.
>  * It helps other Python implementations immensely.  PyPy, IronPython,
> and Jython are all going to have to provide this library eventually (one
> supposes).  Forcing them each to re-implement it will mean it will be
> that much longer before they support it.

We don't maintain any other features in two languages for those
purposes. IMO, it will just be more of a burden to fix bugs in two
different places as compared to the advantages you mention.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4565] Rewrite the IO stack in C

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

> We don't maintain any other features in two languages for those
purposes. IMO, it will just be more of a burden to fix bugs in two
different places as compared to the advantages you mention.

Surely the majority of the burden is imposed by the C implementation.  I
expect that 90% of the time spent fixing bugs will be spent fixing them
in C.  So for only a slightly increased maintenance cost, a massive
advantage is gained for other Python implementations.  If the general
well-being and popularity of Python isn't a concern of CPython
developers, then perhaps the benefits can still be preserved at minimal
cost to the CPython developers by letting some Jython, IronPython, or
PyPy developers maintain the Python implementation of the io library in
the CPython source tree (rather than making them copy it elsewhere where
it will more frequently get out of sync, and where
Jython/IronPython/PyPy might waste effort in duplicating maintenance).

Or maybe none of them will care or object to the removal of the Python
version from CPython.  It might at least be worth asking first, though.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2771] test issue

[Martin v. Löwis]

Martin v. Löwis  added the comment:

More testing.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2771] test issue

[Martin v. Löwis]

Martin v. Löwis  added the comment:

Testing 1..2..3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5322] Python 2.6 object.__new__ argument calling autodetection faulty

[Armin Ronacher]

New submission from Armin Ronacher :

In 2.6 a deprecation warning was added if `object.__new__` was called
with arguments.  Per se this is fine, but the detection seems to be faulty.

The following code shows the problem:

>>> class A(object):
... def __new__(self):
... raise TypeError('i do not exist')
... 
>>> class B(A):
... __new__ = object.__new__
... def __init__(self, x):
... self.x = x
... 
>>> B(1)
__main__:1: DeprecationWarning: object.__new__() takes no parameters
<__main__.B object at 0x88dd0>

In the `B` case `__new__` is not overridden (in the sense that it
differs from object.__new__) but `__init__` is.  Which is the default
behaviour.  Nonetheless a warning is raised.

I used the pattern with the "__new__ switch" to achieve a
cStringIO.StringIO behavior that supports typechecks:  IterIO() returns
either a IterI or IterO object, both instances of IterIO so that
typechecks can be performed.

Real-world use case here:
http://dev.pocoo.org/projects/werkzeug/browser/werkzeug/contrib/iterio.py

--
messages: 82497
nosy: aronacher
severity: normal
status: open
title: Python 2.6 object.__new__ argument calling autodetection faulty
type: behavior
versions: Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue936813] fast modular exponentiation

[Trevor Perrin]

Trevor Perrin  added the comment:

Hi Mark,

Let me know if I can give you any help with this.  The original patch
was split into 3 parts.  The only part remaining unapplied is the
Montgomery Reduction.  

It appeared to be a significant speedup when I was last testing, and is
frequently used in other modular exponentiation libraries, but it does,
admittedly, complicate the code.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue936813] fast modular exponentiation

[Gregory P. Smith]

Changes by Gregory P. Smith :


--
nosy: +gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5323] document expected/required behavior of 3.x io subsystem with respect to buffering

[R. David Murray]

New submission from R. David Murray :

The python 3.x io library appears to allow mixing calls to __next__ and
calls to readline.  As another consequence, where previously it was
necessary to use 'readline' to read single lines from a pipe without
blocking waiting for a buffer fill, now one can apparently use 'for'.

Reading the code in io.py, it seems as though this is intentional:
readline and __next__ use the same buffer, and the method on
TextIOWrapper that fills the buffer calls 'read1', which in the one
place where it has a docstring says that only as much data as is
available is read, in contrast to 'read', which reads exactly n bytes
(to EOF).

Assuming this is the intended behavior, it should be documented, and if
they do not exist (I didn't see any) tests should be added to confirm
the behavior.  If this behavior is an implementation artifact, then this
should be documented so that code is less likely to depend on it.

Once I know whether or not this behavior _should_ be part of the test
suite, I'll be happy to work on doc and test patches.

--
components: Library (Lib)
messages: 82499
nosy: bitdancer
severity: normal
status: open
title: document expected/required behavior of 3.x io subsystem with respect to 
buffering
type: behavior
versions: Python 3.0, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5176] Special-case string formatting in BINARY_MODULO implementation

[Jeffrey Yasskin]

Jeffrey Yasskin  added the comment:

Looks good to me.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4565] Rewrite the IO stack in C

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Hello JP,

> Surely the majority of the burden is imposed by the C implementation.  I
> expect that 90% of the time spent fixing bugs will be spent fixing them
> in C.

Hmm, it depends. It's probably true in general, but I suspect a fair
amount of work also went into getting the Python implementation correct,
since there are things in there that are tricky regardless of the
implementation language (I'm especially thinking of the TextIOWrapper
seek() and tell() methods).
(and there are still bugs in the Python implementation btw.)

> If the general
> well-being and popularity of Python isn't a concern of CPython
> developers, then perhaps the benefits can still be preserved at minimal
> cost to the CPython developers by letting some Jython, IronPython, or
> PyPy developers maintain the Python implementation of the io library in
> the CPython source tree

Well, if it is part of the CPython source tree, we (CPython developers)
can't realistically ignore it by saying it's someone else's job.

> Or maybe none of them will care or object to the removal of the Python
> version from CPython.  It might at least be worth asking first, though.

In any case, it must first be asked on python-dev. We're not gonna dump
the code without telling anybody anything :)

cheers

Antoine.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4565] Rewrite the IO stack in C

[Raymond Hettinger]

Raymond Hettinger  added the comment:

[Benjamin Peterson]
> I think we should just drop the Python implementations. There's no point
> in trying to keep two implementations around.

I disagree.  I've found great value in keeping a pure python version
around for things I've converted to C.   The former serves as
documentation, as a tool for other implementations (like PyPy
IronPython, and Jython), and as a precise spec.  The latter case
is especially valuable (otherwise, the spec becomes whatever
CPython happens to do). 

Also, I've found that once the two are in-sync, keeping it that way
isn't hard.  And, there effort for keeping them in-sync is a good
way to find bugs.

In the heapqmodule, we do a little magic in the test suite to
make sure the tests are run against both.  It's not hard.


Raymond

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4565] Rewrite the IO stack in C

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

Hi Antoine,

> > Surely the majority of the burden is imposed by the C
implementation.  I expect that 90% of the time spent fixing bugs will be
spent fixing them in C.

> Hmm, it depends. It's probably true in general, but I suspect a fair
amount of work also went into getting the Python implementation correct,
since there are things in there that are tricky regardless of the
implementation language (I'm especially thinking of the TextOWrapper
seek() and tell() methods). (and there are still bugs in the Python
implementation btw.)

Indeed, I'm sure a lot of work went into the Python implementation - and
hopefully that work *saved* a huge amount of work when doing the C
implementation.  That's why people prototype things in Python, right? :)
 So it seems to me that keeping the Python implementation is useful for
CPython, since if it made working on the C implementation easier in the
past, it will probably do so again in the future.

Basically, my point is that maintaining C and Python versions is
*cheaper* than just maintaining the C version alone.  The stuff I said
about other VMs is true too, but it doesn't seem like anyone here is
going to be convinced by it ;)  (and I haven't spoked to any developers
for other VMs about whether they really want it, anyway).

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5324] __subclasses__ undocumented

[Michael Foord]

New submission from Michael Foord :

I can't find any documentation for the __subclasses__ magic method. At
the very least needed for language implementors.

--
assignee: georg.brandl
components: Documentation
messages: 82504
nosy: georg.brandl, mfoord
severity: normal
status: open
title: __subclasses__ undocumented

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5322] Python 2.6 object.__new__ argument calling autodetection faulty

[Armin Ronacher]

Armin Ronacher  added the comment:

The problem seems to be caused by tp_new being slot_tp_new which then
invokes whatever __new__ in the class dict is.

I'm not so sure what would be the solution to this.  One could of course
check if tp_new is either object_new or slot_tp_new and in the latter
case check if the class dict's __new__ item is object_new...

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5306] Python 3.1 won't compile under Visual Studio 2005

[Amaury Forgeot d'Arc]

Changes by Amaury Forgeot d'Arc :


--
assignee:  -> amaury.forgeotdarc
nosy: +amaury.forgeotdarc

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5306] Python 3.1 won't compile under Visual Studio 2005

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

I merged the change manually, and came to the same patch as ocean-city;

Then I noticed that os.device_encoding() (new in python 3.0) needs the 
same check as well.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4565] Rewrite the IO stack in C

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> Basically, my point is that maintaining C and Python 
> versions is *cheaper* than just maintaining the C 
> version alone.

Well said.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4565] Rewrite the IO stack in C

[Gregory P. Smith]

Gregory P. Smith  added the comment:

+1 to setting it up so that unit tests are always run against both and 
keeping both.

--
nosy: +gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4565] Rewrite the IO stack in C

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> +1 to setting it up so that unit tests are always run against both and 
> keeping both.

If this is the way forward I recommend putting the pure Python versions
into a separate module, eg pyio.py (although the name is not very
elegant). It will make the separation clean and obvious.

(and perhaps it will have the side-effect of improving startup time,
although I'm not really worried about this)

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue835176] [2.3.2] bz2 test failure on AIX 4.3.2, Tru64 UNIX

[Daniel Diniz]

Changes by Daniel Diniz :


--
resolution:  -> out of date
stage:  -> committed/rejected
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1210326] comma separated cookie values

[Daniel Diniz]

Changes by Daniel Diniz :


--
resolution:  -> invalid
stage:  -> committed/rejected
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1682241] Problems with urllib2 read()

[Daniel Diniz]

Changes by Daniel Diniz :


--
resolution:  -> invalid
stage: test needed -> committed/rejected
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue775340] OSX 'freeze' bug

[Daniel Diniz]

Changes by Daniel Diniz :


--
resolution:  -> out of date
stage: test needed -> committed/rejected
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue780354] socket.makefile() isn't compatible with marshal/cPickle/etc

[Daniel Diniz]

Changes by Daniel Diniz :


--
resolution:  -> invalid
stage:  -> committed/rejected
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1169633] Install fail code 2932 after fail to copy python_icon.exe

[Daniel Diniz]

Changes by Daniel Diniz :


--
resolution:  -> works for me
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1111100] csv reader barfs encountering quote when quote_none is set

[Daniel Diniz]

Changes by Daniel Diniz :


--
resolution:  -> out of date
stage:  -> committed/rejected
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue995956] TclError with intel's hypertheading

[Daniel Diniz]

Changes by Daniel Diniz :


--
resolution:  -> out of date
stage: test needed -> committed/rejected
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue815753] SCO_SV: many modules cannot be imported

[Daniel Diniz]

Changes by Daniel Diniz :


--
resolution:  -> out of date
stage: test needed -> committed/rejected
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue727732] getpath.c-generated prefix wrong for Tru64 scripts

[Daniel Diniz]

Changes by Daniel Diniz :


--
resolution:  -> out of date
stage: test needed -> committed/rejected
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue875654] add support for installations compiled for debugging

[Daniel Diniz]

Changes by Daniel Diniz :


--
resolution:  -> rejected
stage:  -> committed/rejected
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue872815] How to pass the proxy server use socket

[Daniel Diniz]

Changes by Daniel Diniz :


--
resolution:  -> invalid
stage:  -> committed/rejected
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue854918] Configurable SSL handshake

[Daniel Diniz]

Changes by Daniel Diniz :


--
resolution:  -> out of date
stage: test needed -> committed/rejected
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5305] imaplib should support international mailbox names

[James Henstridge]

James Henstridge  added the comment:

I'll have a go at implementing the algorithm.  It looks like the
modifications to UTF-7 are large enough that you can't do a search and
replace on the output of the existing UTF-7 codec, so it'll probably
require new code.

Would String2Mailbox and Mailbox2String utility functions be appropriate
here?

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3067] setlocale fails with unicode strings on Py2 and with byte strings on Py3

[Ezio Melotti]

Ezio Melotti  added the comment:

FWIW the type("") is gone in Py3, now it is:
"if locale and not isinstance(locale, _builtin_str):"
where "from builtins import str as _builtin_str"
(http://svn.python.org/view/python/branches/py3k/Lib/locale.py?view=markup)

However Py3.0 now raises the same error when the second arg is a byte
string:
>>> locale.setlocale(locale.LC_ALL, b'ja_JP.utf8')
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Programs\Python30\lib\locale.py", line 500, in setlocale
locale = normalize(_build_localename(locale))
  File "C:\Programs\Python30\lib\locale.py", line 408, in _build_localename
language, encoding = localetuple
ValueError: too many values to unpack

On Py3, locale.setlocale() should allow only unicode strings and reject
byte strings.

--
components: +Unicode
nosy: +ezio.melotti
title: setlocale Tracebacks on unicode locale strings -> setlocale fails with 
unicode strings on Py2 and with byte strings on Py3
versions: +Python 2.6, Python 3.0

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5312] errno not being set

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Thanks for the diagnostic, Georg! Fixed in r69794.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5325] "SyntaxError: None" when the name of the dir contains non-ascii chars

[Ezio Melotti]

New submission from Ezio Melotti :

Step to reproduce:
1) create a directory with non-ascii chars in the name
2) create a python module with a syntax error (I used an unclosed '(')
3) execute the module.py directly ('module.py', not 'python module.py')

I tested this only on Windows, with Python3 as the default interpreter
used to execute *.py files, this is the output:

# ascii dir, works fine
D:\>module1.py
  File "D:\module1.py", line 21
   ^
SyntaxError: invalid syntax
# moving to non-ascii dir
D:\>cd äåæ
# non ascii-dir, fails
D:\äåæ>module1.py
SyntaxError: None
# here is using py2.6, but with 'python module1.py' it doesn't print the
dir name
D:\äåæ>python module1.py
  File "module1.py", line 21
   ^
SyntaxError: invalid syntax
# same as before but with py3
D:\äåæ>python3 module1.py
  File "module1.py", line 21
   ^
SyntaxError: invalid syntax

# with print(sys.version) in module1.py
D:\äåæ>module1.py
3.0 (r30:67507, Dec  3 2008, 20:14:27) [MSC v.1500 32 bit (Intel)]
D:\äåæ>python module1.py
2.6 (r26:66721, Oct  2 2008, 11:35:03) [MSC v.1500 32 bit (Intel)]
D:\äåæ>python3 module1.py
3.0 (r30:67507, Dec  3 2008, 20:14:27) [MSC v.1500 32 bit (Intel)]

This seems to happen only with SyntaxErrors, I tested a couple of other
errors and it seems to work:

# with print(sys.version) and 5/0 in module1
# here it prints the dir name without problems (but it doesn't show '5/0')
D:\äåæ>module1.py
3.0 (r30:67507, Dec  3 2008, 20:14:27) [MSC v.1500 32 bit (Intel)]
Traceback (most recent call last):
  File "D:\äåæ\module1.py", line 3, in 
ZeroDivisionError: int division or modulo by zero

D:\äåæ>python module1.py
2.6 (r26:66721, Oct  2 2008, 11:35:03) [MSC v.1500 32 bit (Intel)]
Traceback (most recent call last):
  File "module1.py", line 3, in 
5/0
ZeroDivisionError: integer division or modulo by zero

D:\äåæ>python3 module1.py
3.0 (r30:67507, Dec  3 2008, 20:14:27) [MSC v.1500 32 bit (Intel)]
Traceback (most recent call last):
  File "module1.py", line 3, in 
5/0
ZeroDivisionError: int division or modulo by zero

--
components: Unicode
messages: 82513
nosy: ezio.melotti
severity: normal
status: open
title: "SyntaxError: None" when the name of the dir contains non-ascii chars
type: behavior
versions: Python 3.0

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3446] center, ljust and rjust are inconsistent with unicode parameters

[Ezio Melotti]

Ezio Melotti  added the comment:

Indeed this behavior doesn't seem to be documented.

When the string is unicode and the fillchar non-unicode Python
implicitly tries to decode the fillchar (and possibly it raises a
TypeError if it's not in range(0,128)):
>>> u'x'.center(5, 'y') # unicode string, non-unicode (str) fillchar
u'yyxyy' # the fillchar is decoded


When the string is non-unicode it only accepts a non-unicode fillchar
(e.g. 'x'.center(5, 'y')) and it raises a TypeError if the fillchar is
unicode:
>>> 'x'.center(5, u'y') # non-unicode (str) string, unicode fillchar
Traceback (most recent call last):
  File "", line 1, in 
TypeError: center() argument 2 must be char, not unicode

If it tries to decode the fillchar when the string is unicode, it could
also try to encode the unicode fillchar (and possibly raise a TypeError)
when the string is non-unicode.

Py3, instead, seems to have the opposite behavior. It implicitly encodes
unicode fillchars into byte strings when the string is a byte string but
it doesn't decode a byte fillchar if the string is unicode:

>>> b'x'.center(5, 'y') # byte string, unicode fillchar
b'yyxyy' # the fillchar is encoded
>>> 'x'.center(5, b'y') # unicode string, byte fillchar
Traceback (most recent call last):
  File "", line 1, in 
TypeError: The fill character cannot be converted to Unicode

In the doc [1] there's written that "The methods on bytes and bytearray
objects don’t accept strings as their arguments, just as the methods on
strings don’t accept bytes as their arguments." so b'x'.center(5, 'y')
should probably raise an error on Py3 (I could open a new issue for this).

[1]:
http://docs.python.org/3.0/library/stdtypes.html#bytes-and-byte-array-methods
- In the note

--
nosy: +ezio.melotti
versions: +Python 2.6, Python 3.0

___
Python tracker 

___
___
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?

[Ezio Melotti]

Ezio Melotti  added the comment:

I'd close this as "won't fix", because (IMHO) ranges like [9-A]
shouldn't be used at all, so I won't expect it to work properly.

FWIW Perl doesn't seem to match the '_', even with the 'i' flag. Tested
with: perl -e '$s = ("_" =~ /[9-A]/); print $s' and perl -e '$s = ("_"
=~ /[9-A]/i); print $s'. It matches ":" with [9-A] and "_" with [9-a]
though (both without the 'i' flag).

--
nosy: +ezio.melotti

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5326] Wrong anchors in "What's New in Python 2.5"

[Ezio Melotti]

New submission from Ezio Melotti :

Some anchors of the "What's New in Python 2.5" page [1] are wrong (both
in the table of contents and on the titles):
New, Improved, and Removed Modules
The ctypes package
The ElementTree package
The hashlib package
The sqlite3 package
The wsgiref package


[1]: http://docs.python.org/whatsnew/2.5.html

--
assignee: georg.brandl
components: Documentation
messages: 82516
nosy: ezio.melotti, georg.brandl
severity: normal
status: open
title: Wrong anchors in "What's New in Python 2.5"

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5327] Broken link in "What's New in Python 2.5"

[Ezio Melotti]

New submission from Ezio Melotti :

The link in the second paragraph of "The ElementTree package" [1]
section of the "What's New in Python 2.5" page is broken.

[1]: http://docs.python.org/whatsnew/2.5.html#module-hashlib (the name
of this anchor is also wrong, see #5326)

--
assignee: georg.brandl
components: Documentation
messages: 82517
nosy: ezio.melotti, georg.brandl
severity: normal
status: open
title: Broken link in "What's New in Python 2.5"

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3595] Windows base64 Decode

[Ezio Melotti]

Ezio Melotti  added the comment:

This can be closed if Ahir doesn't provide the script.

--
nosy: +ezio.melotti

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3742] Parsing XML file with Unicode characters causes problem

[Ezio Melotti]

Ezio Melotti  added the comment:

The encoding used by the windows terminal (usually cp850) is not able to
encode all the characters, so when you print the text that you extract
from the xml file the terminal is not able able to display some
characters. If you remove the print() it works fine. You can also try to
write the results on a file using utf-8.

This issue can be closed.

--
nosy: +ezio.melotti

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com