[issue5505] sys.stdin.read() doesn't return after first EOF on Windows

[Fan Decheng]

New submission from Fan Decheng :

Platform: Windows Vista x64
Python version: 3.0.1 x64

When I use sys.stdin.readlines(), it correctly ends when I enter ^Z 
(ctrl-Z) on the console (this is the EOF on the console). However when 
I call sys.stdin.read(), it doesn't end when ^Z is entered. It ends 
when I enter the second ^Z.

Repro steps:
1. Open python.
2. Type:
import sys
sys.stdin.read()
3. Type:
Hello
^Z
4. Note the above ^Z should be followed by a Return.
Result:
The function call doesn't end. If I enter another ^Z, it ends.
Expected result:
The function call ends.

--
components: Library (Lib)
messages: 83736
nosy: r_mosaic
severity: normal
status: open
title: sys.stdin.read() doesn't return after first EOF on Windows
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

[issue1529142] Allowing multiple instances of IDLE with sub-processes

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Is there anyone following this thread that thinks the weeble's patch is
not ready to commit?

--
assignee: kbk -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue5502] io-c: TextIOWrapper is faster than BufferedReader but not protected by a lock

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> But it looks that py3k is stronger because it doesn't crash. Is it the 
> power of the GIL?

Yes, it is.
In theory, we needn't take the lock in all of BufferedReader.readline(),
only when calling external code which might itself release the GIL. In
practice, we didn't bother optimizing the lock-taking, for the sake of
simplicity. If the lock really accounts for a significant part of the
runtime cost, we can try to do better.

--

___
Python tracker 

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

[issue5506] io.BytesIO doesn't support the buffer protocol

[Antoine Pitrou]

New submission from Antoine Pitrou :

It may be logical for BytesIO to support the buffer protocol (readable
/and/ writable).

--
components: Library (Lib)
messages: 83740
nosy: pitrou
priority: normal
severity: normal
stage: test needed
status: open
title: io.BytesIO doesn't support the buffer protocol
type: feature request
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

[issue5505] sys.stdin.read() doesn't return after first EOF on Windows

[Antoine Pitrou]

Antoine Pitrou  added the comment:

(cannot reproduce under Linux)

--
nosy: +pitrou

___
Python tracker 

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

[issue5503] multiprocessing/connection.py wrong pipe name under win32

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
assignee:  -> jnoller
nosy: +jnoller
priority:  -> normal
type:  -> behavior
versions: +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

[issue4228] struct.pack('L', -1)

[Andreas Schawo]

Andreas Schawo  added the comment:

As I understand actually the zipfile module possibly creates damaged zip
files after version 2.4 because of '\x00\x00\x00\x00' instead of
'\xff\xff\xff\xff' as header offset. But without any error.

I think the _struct.c should be cleaned in any case. Because we only get
errors in zipfile module when damaged zip files are created. An error
would be appriciated instead of a silenty damaged zip file.

But, why don't boundary check the header offset in zipfile module in a
short private  function and returning '\xff\xff\xff\xff' in case of
overflow? Maybe all longs should be boundary checked if this seems
necassery.

--
nosy: +andreas.schawo

___
Python tracker 

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

[issue5374] optparse special usage tokens conflict with formatting characters

[Andy Buckley]

Andy Buckley  added the comment:

I'm easy either way --- I appreciate that it is a non-issue with new
formatting, but until developers can rely on the presence of Py >= 2.6,
%-formatting wil continue to be widely used.

Since optparse's special use of %-delimited tokens clashes with the
established formatting in a way that could arguably do with
clarification (I was blind enough to the solution to start this ticket),
I think it could be useful to document it close to the description of
%prog usage. Of course, since I now know the answer, *I* don't need it
to be in the documentation, but it might be helpful to others ;)

--

___
Python tracker 

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

[issue1201569] allow running multiple instances of IDLE

[Tal Einat]

Tal Einat  added the comment:

This should be dropped in favor of issue #1529142, which proposes a
simpler and better solution.

--

___
Python tracker 

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

[issue5507] ctypes configuration fails on mips-linux (and probably Irix)

[Matthias Klose]

New submission from Matthias Klose :

|   File "build/temp.linux-mips-2.6/libffi/fficonfig.py", line 32, in

| ffi_sources += ffi_platforms['MIPS']
| KeyError: 'MIPS'

however the fficonfig.py file has only MIPS_LINUX and MIPS_IRIX keys.

--
assignee: theller
components: ctypes
messages: 83744
nosy: doko, theller
severity: normal
status: open
title: ctypes configuration fails on mips-linux (and probably Irix)
type: compile error
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

[issue4228] struct.pack('L', -1)

[Mark Dickinson]

Mark Dickinson  added the comment:

I don't know the zipfile module very well (i.e., at all),
but as far as I can tell from looking at the source,
there's no use of struct.pack('L', -1) in 2.6 onwards:
it's only potentially a problem in 2.5 (and that isn't
going to change, now that 2.5 is in security-fix only
mode).

Can anyone who understands the zipfile module better than
me confirm this?

--

___
Python tracker 

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

[issue5463] Remove deprecated features from struct module

[Mark Dickinson]

Mark Dickinson  added the comment:

I think you're right about issue 4228:  we should go ahead and
clean up the struct module anyway.  As far as I can tell, only
the Python 2.5 zipfile module is using the deprecated behaviour.

The _struct.c portion of your patch looks fine.  I think there's
still some work to do on the test_struct file:  for example,
removing references to PY_STRUCT_OVERFLOW_MASKING.

I'd also like to remove the deprecated float handling, but it's
probably better to do that in a separate patch once this patch is in.

Changing title to better reflect the current patch.

--
title: Compiler warning get_ulong is never used 3.x -> Remove deprecated 
features from struct module
type: compile error -> feature request

___
Python tracker 

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

[issue4015] [patch] make installed scripts executable on windows

[Benny Bach]

Benny Bach  added the comment:

If you have to name the script with a .bat extension it is not portable
to other platforms or did I misunderstand something?

The point of generating the bat file is to be able to use the same
script on all platforms.

--

___
Python tracker 

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

[issue4508] distutils compiler not handling spaces in path to output/src files

[C. E. Ball]

C. E. Ball  added the comment:

I also found this bug while using SciPy's weave on Windows XP to compile
some inline c/c++ code.

Thorney's distutils_compiler_quoting.patch fixed the problem for me.


Here is the relevant part of the traceback (I hope):
"""
Found executable C:\Program Files\Topographica\python_topo\mingw\bin\g++.exe
g++.exe:
c:\docume~1\ceball\locals~1\temp\ceball\python25_intermediate\compiler_
894ad5ed761bb51736c6d2b7872dc212\Release\program: No such file or directory
g++.exe:
files\topographica\python_topo\lib\site-packages\weave\scxx\weave_imp.o:
 No such file or directory
"""

Chris

--
nosy: +ceball

___
Python tracker 

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

[issue5463] Remove deprecated features from struct module

[Andreas Schawo]

Andreas Schawo  added the comment:

I agree with you. A separate patch will do better.

In the next days I'm able to provide a new patch with the test_struct
cleanup.

Currently all tests succeeded on Windows and Linux. So I think no other
module relies on this feature explicitly.

I've already checked the documentation, but there are no references to
overflow masking. So there's nothing to do for now.

--

___
Python tracker 

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

[issue4015] [patch] make installed scripts executable on windows

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

On posix platform, build_scripts already updates the #! line to refer to
the target interpreter, and changes the file mode.
On Windows, it could change the extension as well. Or does it causes
problems?

--

___
Python tracker 

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

[issue4474] PyUnicode_FromWideChar incorrect for characters outside the BMP (unix only)

[Mark Dickinson]

Mark Dickinson  added the comment:

Committed to py3k, r70452.

Since this is partway between a bugfix and a new feature, I suggest that 
it's not worth merging it to 3.0 (or 2.6).  It should be backported to 
2.7, however;  I'll do this after verifying that the py3k buildbots are 
happy.

--
versions:  -Python 2.6, 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

[issue5508] maximum recursion depth exceeded in __subclasscheck__

[ganges master]

New submission from ganges master :

this is similar to bug #5370, but this for is a different reason. also,
i have seen several sites on google that mention it, so it has happened
to quite a few people.

the bug is that when calling dir() on a object, it looks for __members__
and __methods__, which might not exist, thus invoking __getattr__ (if it
exists).

if __getattr__ fails, say, due to a never ending recusion, the exception
is silently swallowed. this was the behavior in py2.5. since 2.6, it
emits a warning (that looks like PyErr_WriteUnraisable) with the
strangest message:

Exception RuntimeError: 'maximum recursion depth exceeded in
__subclasscheck__' in  ignored

this is very confusing. either dir() raises this exception, or silently
ignore it, but displaying this message is only confusing.

i haven't been able to detect why this happens:
 * the source of this exception, merge_list_attr, calls PyErr_Clear
 * nobody seems to call PyErr_WriteUnraisable

here's a snippet:

class Foo(object):
def __getattr__(self, name):
return self.x  # which will recursively call __getattr__

>>> f = Foo()
>>> print dir(f)
Exception RuntimeError: 'maximum recursion depth exceeded in
__subclasscheck__' in  ignored
Exception RuntimeError: 'maximum recursion depth exceeded in
__subclasscheck__' in  ignored
['__class__', '__delattr__', '__dict__', '__doc__', '__format__',
'__getattr__', '__getattribute__', '__hash__', '__init__', '__module__',
'__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__',
'__sizeof__', '__str__', '__subclasshook__', '__weakref__']

--
components: Interpreter Core
messages: 83752
nosy: gangesmaster, georg.brandl
severity: normal
status: open
title: maximum recursion depth exceeded in __subclasscheck__
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

[issue4773] HTTPMessage not documented and has inconsistent API across 2.6/3.0

[Brad Miller]

Changes by Brad Miller :


--
nosy: +bmiller

___
Python tracker 

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

[issue1222] locale.format bug if thousand separator is space (french separator as example)

[Mark Dickinson]

Mark Dickinson  added the comment:

r70357 seems to have caused the sparc solaris py3k buildbot to start failing on 
test_locale:


==
FAIL: test_integer_grouping_and_padding (test.test_locale.TestNumberFormatting)
--
Traceback (most recent call last):
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test_locale.py", 
line 181, 
in test_integer_grouping_and_padding
out=('4%s200' % self.sep).rjust(10))
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test_locale.py", 
line 143, 
in _test_format
func=locale.format, **format_opts)
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test_locale.py", 
line 139, 
in _test_formatfunc
func(format, value, **format_opts), out)
AssertionError: ' 4200' != '  4200'


Any idea what's going on here?

--
nosy: +marketdickinson

___
Python tracker 

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

[issue4474] PyUnicode_FromWideChar incorrect for characters outside the BMP (unix only)

[Mark Dickinson]

Mark Dickinson  added the comment:

Backported to the trunk in r70454.  Thanks, all!

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

[issue5505] sys.stdin.read() doesn't return after first EOF on Windows

[Hirokazu Yamamoto]

Hirokazu Yamamoto  added the comment:

I can reproduce this on coLinux(debian). But coLinux is running on
windows, so its console behavior may not be same as native linux.
(You need to use Ctrl+D on coLinux instead of Ctrl+Z)

--
nosy: +ocean-city

___
Python tracker 

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

[issue5505] sys.stdin.read() doesn't return after first EOF on Windows

[Hirokazu Yamamoto]

Hirokazu Yamamoto  added the comment:

With following patch for investigation, (release30-maint)

Index: Lib/io.py
===
--- Lib/io.py   (revision 70450)
+++ Lib/io.py   (working copy)
@@ -57,6 +57,7 @@
 
 import os
 import abc
+import sys
 import codecs
 import _fileio
 # Import _thread instead of threading to reduce startup cost
@@ -931,6 +932,7 @@
 while True:
 # Read until EOF or until read() would block.
 chunk = self.raw.read()
+print(">", repr(chunk), file=sys.stderr)
 if chunk in empty_values:
 nodata_val = chunk
 break

///

I got this result.

>>> sys.stdin.read()
abc
^Z
> b'abc\n'
^Z
> b''
'abc\n'

To get empty chunk, we need to hit CTRL-Z twice.

--

___
Python tracker 

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

[issue1222] locale.format bug if thousand separator is space (french separator as example)

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Hi Mark,

> AssertionError: ' 4200' != '  4200'
> 
> Any idea what's going on here?

The problem seems to be that the thousands separator on the Solaris
variant of en_US is an empty string (rather than a comma) (*), and
apparently it hits a bug in the padding mechanism (which perhaps assumes
that the thousands separator is always a 1-character string).

(*) (another reason not to use any C locale-based mechanism for
localization, by the way...)

--

___
Python tracker 

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

[issue1222] locale.format bug if thousand separator is space (french separator as example)

[Antoine Pitrou]

Antoine Pitrou  added the comment:

By the way, Martin, do you have any idea why the Solaris buildbot
doesn't seem to be enabled on trunk?

--

___
Python tracker 

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

[issue5509] cPickle - module object has no attribute

[Nathaniel Troutman]

New submission from Nathaniel Troutman :

If I define a class Foo in module A and in module A pickle out a list of
Foo objects to 'foo.pkl', then in module B attempt to unpickle 'foo.pkl'
I recieve the error "AttributeError: 'module' object has no attribute 'Foo'"

Attached are:
Foo.py which defines the class Foo and pickles out a list of objects

LoadFoo.py attempts to load the list of objects pickled by Foo

I'm running Vista with "Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08)
[MSC v.1310 32 bit (Intel)] on win32"

--
components: None
files: Foo.py
messages: 83759
nosy: ntroutman
severity: normal
status: open
title: cPickle - module object has no attribute
versions: Python 2.5
Added file: http://bugs.python.org/file13364/Foo.py

___
Python tracker 

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

[issue5509] cPickle - module object has no attribute

[Nathaniel Troutman]

Nathaniel Troutman  added the comment:

Why can I only attach one file at a time?

--
Added file: http://bugs.python.org/file13365/LoadFoo.py

___
Python tracker 

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

[issue1222] locale.format bug if thousand separator is space (french separator as example)

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Trying a fix in r70458.

--

___
Python tracker 

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

[issue1322] platform.dist() has unpredictable result under Linux

[Matthias Klose]

Matthias Klose  added the comment:

MAL, please can we add zooko's patch in some form? The current
implementation assumes an implementation, which doesn't exist on all
platforms, and just dividing linux distributions in "unsupported" and
"supported" seems to be odd.

You cite some URL's in platform.py:

 - http://linuxmafia.com/faq/Admin/release-files.html
 
   "Linux System Base-compliant systems should have a file called
   /etc/lsb_release, which may be in addition to a distribution-
   specific file."

   The standard doesn't say anything like this.

 - http://linux.die.net/man/1/lsb_release
   This is one implementation, not more. The current platform.py
   implementation seems to require this particular implementation.

The only relevant URL is missing in this file:
http://refspecs.freestandards.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/lsbrelease.html

--

___
Python tracker 

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

[issue1322] platform.dist() has unpredictable result under Linux

[Matthias Klose]

Changes by Matthias Klose :


___
Python tracker 

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

[issue4015] [patch] make installed scripts executable on windows

[Benny Bach]

Benny Bach  added the comment:

Ok - I see what you mean. I can't see any problems with it. However 
generating a separate bat file has the advantage that you can still 
invoke the original script by calling python explicitly.

--

___
Python tracker 

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

[issue5508] maximum recursion depth exceeded in __subclasscheck__

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Here is the reason. Starting from Python 2.6, classes can redefine
subclass checking using a special method named __subclasscheck__. Since
this method can contain arbitrary code, we have to guard against
recursion when calling it. Therefore, the recursion count is incremented
before doing a subclass checking.

Now the problem is that when checking for an exception, we do exactly
that: check whether the raised exception is a subclass of a given type.
If the raised exception occurred just after a recursion overflow, it can
happen that subclass checking overflows the recursion count again.
However, since we don't want the newly raised exception (during
exception subclass checking) to overwrite the original one, so we just
write out it (using PyErr_WriteUnraisable, precisely) and then discard it.

That's where these strange messages come from.
(note: py3k has a slightly different recursion checking mechanism and
doesn't print such messages)

--
nosy: +amaury.forgeotdarc, loewis, pitrou

___
Python tracker 

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

[issue1322] platform.dist() has unpredictable result under Linux

[Zooko O'Whielacronx]

Zooko O'Whielacronx  added the comment:

doko: thanks for your interest encouraging more formal and generic
solutions to this.


For what it is worth, the current version of my patch (used in Tahoe) is
here:

http://allmydata.org/trac/tahoe/browser/src/allmydata/__init__.py?rev=20081125155118-92b7f-f74fc964ebd9d3c59afde68b6688c56ce20cca39#L31

I had to add a special case for Arch Linux, which gets triggered after
the three main cases.  The cases currently are, in order:

1.  Parse /etc/lsb-release (fast, semi-de-facto-standard, generic,
hopefully a future de-jure-standard).
2.  Invoke the Python Standard Library's platform.dist() (pros: fast,
has lots of customized special cases for different linux distros, cons:
has lots of customized special cases for different linux distros, gives
bogus answers for Ubuntu and Arch Linux)
3.  Subprocess execute "lsb_release" (pros: a real de-jure-standard!
cons: slow, and is not actually a de-facto-standard since many important
Linux installations don't come by default with the package that provides
the de-jure-standard "lsb_release" executable, even though they do come
by default with the de-facto-semi-standard "/etc/lsb-release" file).
4.  Arch Linux

--

___
Python tracker 

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

[issue5509] cPickle - module object has no attribute

[Nathaniel Troutman]

Nathaniel Troutman  added the comment:

I believe I've tracked down the problem. When you run a python module
directly (ie "python Foo.py") any classes defined in the module have
their '__module__' attribute set to '__main__'. Which means the pickle
says the class is in '__main__' of whatever module is trying to load the
file.

I think it would make more sense to actually include the module name,
this means that an external module need simply ensure that the pickled
class's module be imported with the correct name.

--

___
Python tracker 

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

[issue5510] patches for Modules/socketmodule.c for NetBSD

[Ramsey Dow]

New submission from Ramsey Dow :

I couldn't install setuptools (required by gitosis) because Python 2.6.1
didn't install socket when I built it. A little digging and I
uncommented the "_socket socketmodule.c" line in Modules/Setup.
Unfortunately, the Bluetooth socket stuff in Modules/socketmodule.c was
broken under NetBSD. I made this patch and tested on NetBSD 4.0.1.

When researching this bug on bugs.python.org, I noticed issue5400 which,
in order to get Modules/socketmodule.c compiling, disabled Bluetooth
socket support entirely. That isn't necessary. I just had to ensure the
various structure references made use of the proper member names
(according to NetBSD's /usr/include/netbt/bluetooth.h header file). The
changes I made were similar, though not precisely the same, as those for
FreeBSD.

After patching and building:

ram...@wizard /opt/build/runtime/Python-2.6.1$ ./python -bb -E
Lib/test/regrtest.py test_socket
test_socket
1 test OK.

--
components: Build
files: Python-2.6.1.patch
keywords: patch
messages: 83767
nosy: yesmar
severity: normal
status: open
title: patches for Modules/socketmodule.c for NetBSD
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file13366/Python-2.6.1.patch

___
Python tracker 

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

[issue5511] zipfile - add __exit__ attribute to make ZipFile object compatible with with_statement

[J.R. Allen]

New submission from J.R. Allen :

Currently the zipfile.ZipFile class has no __exit__ atribute, so it 
does not work with a with statement as other file objects do.  Can this 
be implemented?

--
components: Library (Lib)
messages: 83768
nosy: petruchio
severity: normal
status: open
title: zipfile - add __exit__ attribute to make ZipFile object compatible with 
with_statement
type: feature request
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

[issue5511] zipfile - add __exit__ attribute to make ZipFile object compatible with with_statement

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
stage:  -> needs patch
versions: +Python 2.7, Python 3.1 -Python 2.6

___
Python tracker 

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

[issue1222] locale.format bug if thousand separator is space (french separator as example)

[Mark Dickinson]

Mark Dickinson  added the comment:

It looks like that did the trick.  Thank you!

--

___
Python tracker 

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

[issue5509] cPickle - module object has no attribute

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Implementing this may be difficult (the module may not be on the search
path when its run and there's no way to determine that). Also, it would
break compatibility. Anyway, it's usually better to define classes that
will be pickled in their own permanent module.

--
nosy: +benjamin.peterson
resolution:  -> rejected
status: open -> closed

___
Python tracker 

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

[issue5482] RFC: improve distutils bdist_rpm so it builds pure python modules as single packages that works across architectures

[Rudd-O]

Rudd-O  added the comment:

ahaha! I have the patch that implements this functionality.

1) it renames the RPM package name to python-%packagename-py2.4 and and
its requirements as well.
2) it autooptimizes (-O1) any RPM built if no optimization has been
configured in setup.cfg, so it works with any SELinux-enabled or any
other MAC-enabled platforms.

patch against distutils of python 2.4.  works with latest setuptools
just fine.

--
keywords: +patch
Added file: 
http://bugs.python.org/file13367/python-2.4-distutils-bdist_rpm-autonames+optimize.patch

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

Committed 30bit_longdigit20.patch to py3k in r70460, with some minor 
variations (incorporate Nick Coghlan's improved error messages
for marshal, fix some comment typos, add whatsnew and Misc/NEWS entries). 

Thanks all for your feedback.

I might get around to backporting this to 2.7 one day...

--
priority: high -> low
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

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

[Mark Dickinson]

Mark Dickinson  added the comment:

That should be r70459, of course.

--

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

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Great!

> Committed 30bit_longdigit20.patch to py3k in r70460, with some minor 
> variations (incorporate Nick Coghlan's improved error messages
> for marshal, fix some comment typos, add whatsnew and Misc/NEWS entries).

--

___
Python tracker 

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

[issue5500] tarfile: path problem in arcname under windows

[Lars Gustäbel]

Lars Gustäbel  added the comment:

At the moment, I am unable to reproduce the problem you describe. I
tried several combinations of what I think you could have meant, but
everything seems to work okay here.
Could you please provide some stand-alone testcase or code to illustrate
that issue?

--

___
Python tracker 

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

[issue4034] traceback attribute error

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Fixed in r70463.

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

[issue5425] 2to3 wrong for types.StringTypes

[Benjamin Peterson]

Benjamin Peterson  added the comment:

I'm rejecting this patch again not because I think it's any worse than
the status quo (I think they're about equally incorrect/correct), but
because this is now released behavior and changing it may result in
backwards incompatibility. Also, people can easily remove this ambiguity
in a 2.x compatible fashion by explicitly listing the types (str,) or
(str, unicode) instead of using the types module.

--
status: open -> closed

___
Python tracker 

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

[issue5396] os.read not handling O_DIRECT flag

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

> I think the policy is to mirror all possible O_* constants, even if they
> are of no use in Python. For example, we also have os.O_DIRECTORY.


Not disagreeing with the conclusion of this ticket, but I would like to
point out that os.O_DIRECTORY isn't useless in Python.  You need it to
use with os.open if you want to open a directory (which you may wish to
do in order to use with os.fsync, for example).

--
nosy: +exarkun

___
Python tracker 

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

[issue1222] locale.format bug if thousand separator is space (french separator as example)

[Eric Smith]

Eric Smith  added the comment:

Antoine Pitrou wrote:
> The problem seems to be that the thousands separator on the Solaris
> variant of en_US is an empty string (rather than a comma) (*), and
> apparently it hits a bug in the padding mechanism (which perhaps assumes
> that the thousands separator is always a 1-character string).
> 
> (*) (another reason not to use any C locale-based mechanism for
> localization, by the way...)

I've come to believe this, too. I'm working on cleaning up the C 
implementations so I can do all of the locale-based formating without 
using the locale functions. I'll use the localeconv values, but that's it.

--
title: locale.format bug if thousand separator is space (french separator as 
example) -> locale.format bug if thousand separator is space (french   
separator as example)

___
Python tracker 

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

[issue4034] traceback attribute error

[STINNER Victor]

STINNER Victor  added the comment:

@benjamin.peterson: Cool! Thanks.

--

___
Python tracker 

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

[issue5512] Streamline integer division

[Mark Dickinson]

New submission from Mark Dickinson :

Here's a patch that streamlines the x_divrem function in 
Objects/longobject.c.  More benchmarks are needed, but the initial 
results are promising:  for py3k, on a 32-bit machine with 15-bit 
digits, Victor's pidigits benchmark runs almost twice as fast with this 
patch (numbers below).

Patch details
=

- Normalize inputs by shifting instead of multiplying and dividing.
  This halves the number of divisions used in the algorithm.

- Streamline innermost loop.

- Save an iteration of outer loop around half the time.

- Save an object allocation:  only 3 allocations per x_divrem call
  instead of 4.

- Remove special case where initial quotient estimate is >= PyLong_BASE.
  There's no need for this, since the 'digit' type holds values up
  to 2*PyLong_BASE - 1.

- Make q type digit instead of type twodigits:  this halves the size
  of the multiplication in the innermost loop.

Benchmark results
=

Using the pidigits_bestof.py script that's posted in the issue 4258 
discussion, on a non-debug build of py3k (r70465), on OS X 10.5.6/Core 2 
Duo:

Unpatched
-
Macintosh-3:py3k dickinsm$ ./python.exe ../pidigits_bestof.py 2000
performing a warm up run...
running
sys.int_info= sys.int_info(bits_per_digit=15, sizeof_digit=2)
Time; 2234.6 ms
Time; 2232.2 ms
Time; 2227.9 ms
Time; 2225.7 ms
Time; 2229.8 ms
Best Time; 2225.7 ms

Patched
---
dickinsm$ ./python.exe ../pidigits_bestof.py 2000
performing a warm up run...
running
sys.int_info= sys.int_info(bits_per_digit=15, sizeof_digit=2)
Time; 1175.6 ms
Time; 1176.5 ms
Time; 1177.3 ms
Time; 1179.5 ms
Time; 1168.5 ms
Best Time; 1168.5 ms

So the patch gives a speedup of around 90%.  This particular benchmark 
is heavy on the divisions though, so I'd expect lesser speedups for 
other benchmarks.

--
assignee: marketdickinson
components: Interpreter Core
files: faster_integer_division.patch
keywords: patch
messages: 83781
nosy: marketdickinson
priority: normal
severity: normal
status: open
title: Streamline integer division
type: performance
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file13368/faster_integer_division.patch

___
Python tracker 

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

[issue5512] Streamline integer division

[STINNER Victor]

STINNER Victor  added the comment:

Would it be possible to include integer benchmark tools to upstream? I 
mean the "pidigit" tool (I didn't wrote this test! I just ported it to 
Python3) and maybe my "bench_int" tool. It could useful to reproduce 
the benchmark on different Python versions and different computers. We 
may open a new issue for each tool?

--
nosy: +haypo

___
Python tracker 

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

[issue5513] "What's New" should say VERY CLEARLY that the type file is gone

[Mitchell Model]

New submission from Mitchell Model :

MAIN POINT

The Python 3 "What's New" should SCREAM that the type file is gone, not 
just that people should use the function open() to open files, since 
that has been a recommendation for quite a while.

EXPLANATION

In multiple readings of the Python 3 "What's New" I blew right past the 
"Removed file. Use open().", since I've been using open() instead of 
file() for a long time. I didn't notice that unlike the preceding 
several lines, there were no parentheses after "file" and that this line 
was literally saying there was no longer a type called "file".

OBSERVATIONS

(1) If the line is meant to say that you can no longer call file() as a 
function -- which would be strange if it were still a type -- then it is 
missing its parentheses.

(2) If the line is meant to say that there is no longer a file type, as 
it apparently means to say since in fact -- and to my great surprise -- 
there really IS no type called "file" in Python 3 (I discovered that 
doing a dir(file) to check whether file provided method function I 
thought it did instead of taking the time to look it up.) then there is 
a grammatical problem with the line since a (n old) type shouldn't be 
equated to a function call.

(3) I predict that anyone who has more than a passing acquaintance with 
Python 2 will be similarly shocked when they find out that what they get 
back from open() is a _io.TextIOWrapper (and, by the way, that they have 
to import _io or at least _io.TextIOWrapper to be able to do a dir on 
it). Likewise for help(file) and help(_io.TextIOWrapper). There should 
be a very prominent statement that as part of the reimplementation of 
the io system, the type file has been replaced by _io.TextIOWrapper.

RECOMMENDATION

The line
"Removed file. Use open()."
should be replaced with:
"The type file has been removed; use open() to open a file."
or possibly:
"The type file has been replaced by _ioTextIOWrapper; use open() to 
open a file; open returns an instance of _ioTextIOWrapper."

--
assignee: georg.brandl
components: Documentation
messages: 83783
nosy: MLModel, georg.brandl
severity: normal
status: open
title: "What's New" should say VERY CLEARLY that the type file is gone
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

[issue5513] "What's New" should say VERY CLEARLY that the type file is gone

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I'm working on the whatsnew updates and will make sure this is clear.

--
assignee: georg.brandl -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue5512] Streamline integer division

[Mark Dickinson]

Mark Dickinson  added the comment:

Sounds good to me!  An integer benchmark script in the Tools/ directory
would be handy.

--

___
Python tracker 

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

[issue5512] Streamline integer division

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Well, the original code in pidigits is by me :-) (although it's not
stated in the source file).
I haven't tried the patch but the performance work you're doing is
really impressive, Mark!

--
nosy: +pitrou

___
Python tracker 

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

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

[STINNER Victor]

STINNER Victor  added the comment:

Updated version of my macros patch for PyLong type:
 - patch for Python trunk
 - define 3 macros: PyLong_SIGN(x), PyLong_EQUALS_ZERO(x), 
PyLong_NDIGITS(x)
 - just replace code by the equivalent macros

The goal is the make the code easier to read. It would also help if we 
change the PyLong implementation (eg. the 2^30 base patch).

My previous patch was for py3k, the new one is for Python trunk and is 
shorter. I only kept the most simple macros.

--
Added file: http://bugs.python.org/file13369/pylong_macros-2.patch

___
Python tracker 

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

[issue5512] Streamline integer division

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Results here (Athlon X2 3600+ with gcc in 64-bit mode with 30-bit
digits), "pidigits_bestof.py 2000":
- unpatched: 1644.9 ms
- patched: 694.8 ms
!

--

___
Python tracker 

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

[issue5512] Streamline integer division

[STINNER Victor]

STINNER Victor  added the comment:

Useful informations for an integer benchmark:
 - CPU type: 32 or 64 bits, endian
 - Memory size
 - Python version
 - Informations about how Python was compiled
 - Integer implementation: use int_info when it's available, otherwise 
base=2^15

Who has the last version of pidigit tool? Can you attach it here? :-)

--

___
Python tracker 

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

[issue5512] Streamline integer division

[Mark Dickinson]

Mark Dickinson  added the comment:

[Antoine]
> Well, the original code in pidigits is by me :-)

Apologies for the misattribution!

--

___
Python tracker 

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

[issue5512] Streamline integer division

[Mark Dickinson]

Mark Dickinson  added the comment:

Here's the version of pidigits that I was using.

--
Added file: http://bugs.python.org/file13370/pidigits_bestof.py

___
Python tracker 

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

[issue5514] Darwin framework libpython3.0.a is not a normal static library

[Jack Howarth]

New submission from Jack Howarth :

The libpython3.0.a created for Python 3.0.1 isn't a normal static 
library.

file 
/System/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/c
onfig/libpython3.0.a
/System/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/c
onfig/libpython3.0.a: Mach-O universal binary with 3 architectures
/System/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/c
onfig/libpython3.0.a (for architecture x86_64): Mach-O 64-bit 
dynamically linked shared library x86_64
/System/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/c
onfig/libpython3.0.a (for architecture i386):   Mach-O dynamically 
linked shared library i386
/System/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/c
onfig/libpython3.0.a (for architecture ppc7400):Mach-O 
dynamically linked shared library ppc

Due to a bug in Darwin's ar, extraction the object files in this 
abnormal static libraries has been possible with 'ar x'. This bug in ar 
will be fixed in the next Xcode and the abnormal static library that 
python creates will no longer be able to serve as a substitute for a 
true static library. The libpython#.#.#.a files in config should be made 
into normal static libraries for all the currently supported versions of 
python when built as frameworks.

--
components: Macintosh
messages: 83792
nosy: jhowarth
severity: normal
status: open
title: Darwin framework libpython3.0.a is not a normal static library
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

[issue5512] Streamline integer division

[STINNER Victor]

STINNER Victor  added the comment:

New version of pidigit:
 - works on python 2.6, trunk and py3k
 - display Python version, CPU info (bits, endian), PyLong info (base, 
digit size)
 - display usage if no argument is given

--
Added file: http://bugs.python.org/file13371/pidigits-2.py

___
Python tracker 

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

[issue5512] Streamline integer division

[STINNER Victor]

STINNER Victor  added the comment:

Oh, there is no version number of the benchmark tool itself!

--

___
Python tracker 

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

[issue5512] Streamline integer division

[STINNER Victor]

STINNER Victor  added the comment:

My numbers:

# No patch
$ ./python /home/haypo/pidigits-2.py 3000
Python 3.1a1+ (py3k:70466, Mar 18 2009, 23:56:06)
[GCC 4.3.2]
CPU: 64 bits, little endian
PyLong: base=2^30, sizeof(digit)=32 bits
(...)
Best Time; 2300.2 ms

# With faster_integer_division.patch
(...)
Best Time; 1138.1 ms

Ok, it's two times faster on 64 bits CPU!!!

Other notes about pidigits:
 - missing header (no author name, no description)
 - pidigit should also write the number of digits in its output to 
avoid mistakes in comparaisons

--

___
Python tracker 

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

[issue5482] RFC: improve distutils bdist_rpm so it builds pure python modules as single packages that works across architectures

[Rudd-O]

Rudd-O  added the comment:

Improved version of the autonaming patch, now makes rpmbuild accept
files that were installed with spaces on their names.

--
Added file: 
http://bugs.python.org/file13372/python-2.4-distutils-bdist_rpm-autonames+optimize-v2.patch

___
Python tracker 

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

[issue5515] 'n' formatting for int and float handles leading zero padding poorly

[Eric Smith]

New submission from Eric Smith :

I think the way leading zero padding is handled for int and float by
format's 'n' code is a bug.

>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'en_US.UTF8')
'en_US.UTF8'
>>> format(12345, '010n')
'12,345'
>>> format(12345, '09n')
'00012,345'
>>> format(12345, '08n')
'0012,345'
>>> format(12345, '07n')
'012,345'
>>> format(12345, '06n')
'12,345'

When 'n' support was added to Decimal, leading zeros had commas in them:

>>> from decimal import Decimal
>>> format(Decimal(12345), '010n')
'00,012,345'
>>> format(Decimal(12345), '09n')
'0,012,345'
>>> format(Decimal(12345), '08n')
'0,012,345'
>>> format(Decimal(12345), '07n')
'012,345'
>>> format(Decimal(12345), '06n')
'12,345'

Decimal also has the same support for PEP 378's ',' modifier:

>>> format(Decimal(12345), '010,')
'00,012,345'
>>> format(Decimal(12345), '09,')
'0,012,345'
>>> format(Decimal(12345), '08,')
'0,012,345'
>>> format(Decimal(12345), '07,')
'012,345'
>>> format(Decimal(12345), '06,')
'12,345'
>>> 

As I'm implementing PEP 378 for int and float, I'm going to make it work
the same way that Decimal works. For consistency, and because I think
the current behavior is not useful, I'd like to change float and int
formatting with 'n' to match Decimal and PEP 378 for the ',' modifier.

Since I consider this a bug, I'd like to consider backporting it to 2.6
and 3.0, if the changes aren't too intrusive.

--
assignee: marketdickinson
components: Interpreter Core
messages: 83797
nosy: eric.smith, marketdickinson, rhettinger
severity: normal
status: open
title: 'n' formatting for int and float handles leading zero padding poorly
type: behavior
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

[issue5516] equality not reflixive for subclasses of datetime.date and datetime.datetime

[Jess Austin]

New submission from Jess Austin :

While the datetime.date and datetime.datetime classes consistently
handle mixed-type comparison, their subclasses do not:

>>> from datetime import date, datetime, time
>>> d = date.today()
>>> dt = datetime.combine(d, time())
>>> d == dt
False
>>> dt == d
False
>>> class D(date):
... pass
... 
>>> class DT(datetime):
... pass
... 
>>> d = D.today()
>>> dt = DT.combine(d, time())
>>> d == dt
True
>>> dt == d
False

I think this is due to the premature "optimization" of using memcmp() in
date_richcompare().

--
components: Library (Lib)
messages: 83798
nosy: jess.austin
severity: normal
status: open
title: equality not reflixive for subclasses of datetime.date and 
datetime.datetime
type: behavior
versions: Python 2.4, Python 2.5, 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

[issue5516] equality not reflexive for subclasses of datetime.date and datetime.datetime

[Jess Austin]

Changes by Jess Austin :


--
title: equality not reflixive for subclasses of datetime.date and 
datetime.datetime -> equality not reflexive for subclasses of datetime.date and 
datetime.datetime

___
Python tracker 

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

[issue5516] equality not symmetric for subclasses of datetime.date and datetime.datetime

[Jess Austin]

Changes by Jess Austin :


--
title: equality not reflexive for subclasses of datetime.date and 
datetime.datetime -> equality not symmetric for subclasses of datetime.date and 
datetime.datetime

___
Python tracker 

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

[issue5515] 'n' formatting for int and float handles leading zero padding poorly

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I concur with your plan.

BTW, have you checked to see what Java and C# do?

--

___
Python tracker 

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

[issue1520662] support all of strftime(3)

[Tennessee Leeuwenburg]

Tennessee Leeuwenburg  added the comment:

I might start trawling through these issues, slowly ticking them off. Thanks
for the links.

-T

On Wed, Mar 18, 2009 at 1:17 PM, David W. Lambert wrote:

>
> David W. Lambert  added the comment:
>
> (I have no clue where the servers are.)
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--
Added file: http://bugs.python.org/file13373/unnamed

___
Python tracker 

___I might start trawling through these issues, slowly ticking them off. Thanks 
for the links.-TOn Wed, Mar 18, 2009 
at 1:17 PM, David W. Lambert rep...@bugs.python.org> 
wrote:

David W. Lambert lamber...@corning.com> added the 
comment:

(I have no clue where the servers are.)

--

___
Python tracker rep...@bugs.python.org>
http://bugs.python.org/issue1520662>
___
-- 
--Tennessee 
Leeuwenburghttp://myownhat.blogspot.com/";>http://myownhat.blogspot.com/"Don't
 believe everything you think"

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

[issue5513] "What's New" should say VERY CLEARLY that the type file is gone

[Martin v. Löwis]

Martin v. Löwis  added the comment:

> The Python 3 "What's New" should SCREAM that the type file is gone

I don't think the documentation should ever SCREAM.

> "The type file has been replaced by _ioTextIOWrapper; use open() to 
> open a file; open returns an instance of _ioTextIOWrapper."

That would be an incorrect statement: there are multiple types that
replace the 2.x file type. See the documentation of the io module for
details.

--
nosy: +loewis
title: "What's New" should say VERY CLEARLY that the type file is gone -> 
"What's New" should say VERY CLEARLY that the type file   is gone

___
Python tracker 

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