[issue8481] doc: ctypes no need to explicitly allocate writable memory with Structure

[anatoly techtonik]

New submission from anatoly techtonik :

ctypes docs should mention that Structures can be passed with byref() to 
functions expecting pointer to mutable memory without explicit allocation of 
mutable memory block with create_string_buffer() or similar function.

--
assignee: georg.brandl
components: Documentation
messages: 103804
nosy: georg.brandl, techtonik
severity: normal
status: open
title: doc: ctypes no need to explicitly allocate writable memory with Structure
versions: Python 2.6, Python 2.7

___
Python tracker 

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

[issue4256] optparse: provide a simple way to get a programmatically useful list of options

[Andy Buckley]

Andy Buckley  added the comment:

> The backward compatible solution is to have --help-options disabled by 
> default, and ask people to enable it with add_interface=True.

Or to add the option just before arg parsing, if it has not already been 
defined?

Thanks for the patches, Filip!

Andy

--

___
Python tracker 

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

[issue8469] struct - please make sizes explicit

[Mads Kiilerich]

Mads Kiilerich  added the comment:

The more times I read the documentation and your comments I can see that the 
implementation is OK and the documentation is "complete" and can be read 
correctly. Please take this as constructive feedback to improving the 
documentation to make it easier to understand and harder to read incorrectly.

Yes, adding a "Standard size" column would have been very helpful. (I had 
missed the section on "standard" sizes.)

"Standard" is a very general term. And slightly confusing that standard isn't 
the default. Could the term "platform independent" (or "fixed"?) be added as an 
explanation of "standard" - or perhaps used instead?

Programming skills and platform knowledge at C level should not be a 
requirement to understand and use struct, so perhaps the references to C should 
be less high-profile, and perhaps something like this could be added:
"All sizes except trivial 1-byte entries (whatever that means) are platform 
dependent - use calcsize to get the size on your platform."

Perhaps the sections explaining 's', 'p', 'ILqQ', 'P' and '?' could be changed 
to (foot)notes to the table to make it easier to see where they belongs and if 
they can be skipped.

Perhaps "@" in the byte order table could be replaced with "@ (default)"? (And 
perhaps drop "If the first character is not one of these, '@' is assumed.")

The byte order character must come first in the format string and is a key to 
understand the other format characters, so perhaps everything related to that 
should come first?

--

___
Python tracker 

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

[issue8469] struct - please make sizes explicit

[Mark Dickinson]

Mark Dickinson  added the comment:

Thanks for the doc suggestions.

Actually, the current docs were revised recently;  this issue is a helpful 
reminder to me that those doc revisions need to be backported. :)  If you want 
to see the current docs, look at:

http://docs.python.org/dev/library/struct.html

I'm +0 on adding the standard sizes to the table of format codes.

I also agree it might make sense to swap the 'Format Character' section and the 
'Byte Order, Size and Alignment' section.

That's all for now;  I'll look at this properly sometime soon.

The standard/native terminology is fairly ingrained;  I'm not sure whether it's 
really worth changing it, but we can look at the explanations and make sure 
that they're clear.

> Programming skills and platform knowledge at C level should not be a 
> requirement to understand and use struct, so perhaps the references to > C 
> should be less high-profile,

Agreed, though I think the references to C should certainly be there, since 
they will help some users, and since part of the struct module's raison d'etre 
is to allow communication with data written/read by C programs.

The note about ILqQ returning Python longs might be better omitted;  the 
difference between int and long should be irrelevant to most users.

--

___
Python tracker 

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

[issue8482] test_gdb - "(unable to read python frame information)" mismatch

[Nick Coghlan]

New submission from Nick Coghlan :

Remaining failure after resolution of issue8437:
==
FAIL: test_basic_command (test.test_gdb.PyBtTests)
Verify that the "py-bt" command works 
--
Traceback (most recent call last):
  File "/home/ncoghlan/devel/python/Lib/test/test_gdb.py", line 638, in 
test_basic_command  

''')
  File "/home/ncoghlan/devel/python/Lib/test/test_gdb.py", line 158, in 
assertMultilineMatches  

msg='%r did not match %r' % (actual, pattern))  
AssertionError: 'Breakpoint 1 at 0x453510: file Objects/object.c, line 
330.\n[Thread debugging using libthread_db enabled]\n\nBreakpoint 1, 
PyObject_Print (op=42, fp=0x77532780, flags=1)\nat 
Objects/object.c:330\n330\t\treturn internal_print(op, fp, flags, 0);\n#3 Frame 
0x808680, for file /home/ncoghlan/devel/python/Lib/test/gdb_sample.py, line 10, 
in baz (args=(1, 2, 3))\nprint(42)\n#7 (unable to read python frame 
information)\n#10 Frame 0x81a220, for file 
/home/ncoghlan/devel/python/Lib/test/gdb_sample.py, line 7, in bar (a=1, b=2, 
c=3)\nbaz(a, b, c)\n#13 Frame 0x807f00, for file 
/home/ncoghlan/devel/python/Lib/test/gdb_sample.py, line 4, in foo (a=1, b=2, 
c=3)\nbar(a, b, c)\n' did not match '^.*\n#[0-9]+ Frame 0x[0-9a-f]+, for 
file .*gdb_sample.py, line 7, in bar \\(a=1, b=2, c=3\\)\nbaz\\(a, b, 
c\\)\n#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 4, in foo 
\\(a=1, b=2, c=3\\)\nbar\\(a, b, c\\)\n#[0-9]+ Frame 0x[0-9a-f]+, for file 
.*g
 db_sample.py, line 12, in  \\(\\)\nfoo\\(1, 2, 3\\)\n'

--
components: Library (Lib), Tests
keywords: 64bit
messages: 103808
nosy: dmalcolm, haypo, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: test_gdb - "(unable to read python frame information)" mismatch
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue8482] test_gdb - "(unable to read python frame information)" mismatch

[Nick Coghlan]

Nick Coghlan  added the comment:

And Dave's comment from the other issue:

Reading the frame information seems to be highly sensitive to the optimization 
level and the exact version of gcc for the build, and the exact version of gdb, 
alas.  I've been tracking a failure like the one you describe, seen on 64-bit 
with Fedora in our downstream tracker here:
https://bugzilla.redhat.com/show_bug.cgi?id=556975

--

___
Python tracker 

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

[issue8482] test_gdb - "(unable to read python frame information)" mismatch

[Nick Coghlan]

Nick Coghlan  added the comment:

Potentially relevant gcc and gdb version info:

~$ gcc --version
gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO 
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

~$ gdb --version
GNU gdb (GDB) 7.0-ubuntu
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying" and 
"show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
.

Python build is currently just a straight unmodified call to "make". I'll see 
if I still get the error if I tell ./configure to set up for a debug build of 
Python.

--

___
Python tracker 

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

[issue8437] test_gdb: gdb.Frame has no attribute function

[Nick Coghlan]

Nick Coghlan  added the comment:

Remaining problem recorded as issue 8482

--
components: +Library (Lib), Tests
keywords: +64bit -patch
versions: +Python 2.7

___
Python tracker 

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

[issue7332] python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule

[Charles-Francois Natali]

Charles-Francois Natali  added the comment:

> And that report shows only a single thread, so I have to assume that the
8MB figure applies there.

> Nevertheless, we can remove the stack buffer since it's probably
useless. It just seems unlikely to me to be the root cause of the stack
overflow.

If we really have an 8MB stack, yes, it's unlikely. But max stack size is 
inherited by child processes, and see for example streamtuner (one of the 
reports):
http://bugs.gentoo.org/274056

--- src/streamtuner/st-thread.c
+++ src/streamtuner/st-thread.c
@@ -108,1 +108,1 @@
-0x18000, /* 96k, big enough for libcurl */
+0x4, /* change from 96k to 256k */

So if we start with this stack size, we can run out of stack space really 
easily: I counted around 20 bufs allocation in some backtraces, and with 
MAXPATHLEN to 4K, it's 20 * 4 + 16 = 96K used.

There might be another reason. I think that Ubuntu's using gcc SSP feature by 
default, to prevent buffer overflows and friends, so maybe there's something 
going on with this. That would explain why it's only reported on Ubuntu (well, 
they also have more users, but let's assume there's really something specific 
on Ubuntu).

> I'm also getting segfaults in PyMarshal_ReadLastObjectFromFile in Python 
> 2.6.2 (on Ubuntu Jaunty).  It's very sporadic, I've been reproducing it by 
> running a minimal script 100,000 times, and getting a few core dumps.

I've had a look at your backtraces, and when it segfaults, the stack size is 
_really_ far from 8M. So there's realy somthing fishy going on here. Are you 
getting an error message printed beside the usual segmentation fault ? Could 
you try to reproduce with your test script with a python compiled with 
-fno-stack-protector and -U_FORTIFY_SOURCE ?

--

___
Python tracker 

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

[issue6600] MemoryError in AiX 64-bit - PyMem_MALLOC fails in open/fdopen

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Ok, closing then.

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

___
Python tracker 

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

[issue8437] test_gdb: gdb.Frame has no attribute function

[Nick Coghlan]

Nick Coghlan  added the comment:

(Oops, thought I had reverted those accidental edits by reloading the page. I 
guess not)

--
keywords: +patch -64bit

___
Python tracker 

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

[issue8482] test_gdb - "(unable to read python frame information)" mismatch

[STINNER Victor]

STINNER Victor  added the comment:

Readable version of the error message (with newlines):
-
AssertionError: 'Breakpoint 1 at 0x453510: file Objects/object.c, line 330.
[Thread debugging using libthread_db enabled]

Breakpoint 1, PyObject_Print (op=42, fp=0x77532780, flags=1)
at Objects/object.c:330
330 return internal_print(op, fp, flags, 0);
#3 Frame 0x808680, for file /home/ncoghlan/devel/python/Lib/test/gdb_sample.py, 
line 10, in baz (args=(1, 2, 3))
print(42)
#7 (unable to read python frame information)
#10 Frame 0x81a220, for file 
/home/ncoghlan/devel/python/Lib/test/gdb_sample.py, line 7, in bar (a=1, b=2, 
c=3)
baz(a, b, c)
#13 Frame 0x807f00, for file 
/home/ncoghlan/devel/python/Lib/test/gdb_sample.py, line 4, in foo (a=1, b=2, 
c=3)
bar(a, b, c)
' did not match '^.*
#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 7, in bar \(a=1, b=2, 
c=3\)
baz\(a, b, c\)
#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 4, in foo \(a=1, b=2, 
c=3\)
bar\(a, b, c\)
#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 12, in  \(\)
foo\(1, 2, 3\)
'
-

--

___
Python tracker 

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

[issue8483] asyncore.dispatcher.__repr__() is weird

[Dirkjan Ochtman]

New submission from Dirkjan Ochtman :

This is rather confusing:

Python 2.6.4 (r264:75706, Mar  8 2010, 08:41:55)
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket, asyncore
>>> class T:
... pass
...
>>> t = T()
>>> print t
<__main__.T instance at 0x18237a0>
>>> print repr(t)
<__main__.T instance at 0x18237a0>
>>> class A(asyncore.dispatcher):
... pass
...
>>> a = A()
>>> print a
None
>>> print repr(a)
<__main__.A at 0x179c0e0>
>>> class B(asyncore.dispatcher):
... def __init__(self, *args):
... asyncore.dispatcher.__init__(self, *args)
...
>>> sock = socket.socket()
>>> b = B(sock)
>>> print b

>>> print repr(b)
<__main__.B at 0x179c0e0>

Here's dispatcher's __repr__:

def __repr__(self):
status = [self.__class__.__module__+"."+self.__class__.__name__]
if self.accepting and self.addr:
status.append('listening')
elif self.connected:
status.append('connected')
if self.addr is not None:
try:
status.append('%s:%d' % self.addr)
except TypeError:
status.append(repr(self.addr))
return '<%s at %#x>' % (' '.join(status), id(self))

Which doesn't seem excessively complex...

--
components: Library (Lib)
messages: 103816
nosy: djc
severity: normal
status: open
title: asyncore.dispatcher.__repr__() is weird
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

[issue7332] python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule

[Matthias Klose]

Matthias Klose  added the comment:

> That would explain why it's only reported on Ubuntu

the original report is from the rPath distribution.

--

___
Python tracker 

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

[issue8482] test_gdb - "(unable to read python frame information)" mismatch

[Nick Coghlan]

Nick Coghlan  added the comment:

Thanks Victor.

The test actually runs fine under "./configure --with-pydebug", but reverting 
to a plain "./configure" and rebuilding means I get the error again.

Definitely sounds like it could be due to the compiler failing to make some 
relevant info available to the debugger.

--

___
Python tracker 

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

[issue8483] asyncore.dispatcher.__repr__() is weird

[Dirkjan Ochtman]

Changes by Dirkjan Ochtman :


--
nosy: +josiah.carlson, josiahcarlson

___
Python tracker 

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

[issue7332] python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule

[Charles-Francois Natali]

Charles-Francois Natali  added the comment:

> the original report is from the rPath distribution.

Never heard of this one, but 
http://wiki.rpath.com/wiki/rPath_Linux:rPath_Linux_2 states:

Compile with --fstack-protectorand FORTIFY_SOURCE=2 (override in your recipes 
by modifying the securityflags Conary macro), link with GNU hash and -O1, and 
use -fPIE for some key executables.

--

___
Python tracker 

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

[issue8410] Fix emulated lock to be 'fair'

[David Beazley]

David Beazley  added the comment:

I know that multicore processors are all the rage right now, but one thing that 
concerns me about this patch is its effect on single-core systems.  If you 
apply this on a single-CPU, are threads just going to sit there and thrash as 
they rapidly context switch? (Something that does not occur now).

Also, I've done a few experiments and on a single-core Windows-XP machine, the 
GIL does not appear to have any kind of fairness to it (as previously claimed 
here).   Yet, if I run the same experiments on a dual-core PC, the GIL is 
suddenly fair.  So, somewhere in that lock implementation, it seems to adapt to 
the environment.  Do we have to try an emulate that behavior in Unix?   If so, 
how do you do it without it turning into a huge coding mess? 

I'll just mention that the extra context-switching introduced by fair-locking 
has a rather pronounced effect on performance that should be considered even on 
multicore.  I posted some benchmarks in Issue 8299 for Linux and OS-X.  In 
those benchmarks, the introduction of fair GIL locking makes CPU-bound threads 
run about 2-5 times slower than before on Linux and OS-X.

--
nosy: +dabeaz

___
Python tracker 

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

[issue8483] asyncore.dispatcher.__repr__() is weird

[Dirkjan Ochtman]

Dirkjan Ochtman  added the comment:

Current guess for this behavior: dispatcher doesn't have __str__, so 
__getattr__ escalates to _socket.socket.__str__, which gets redirected to 
_socket.socket.__repr__.

--

___
Python tracker 

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

[issue8451] syslog.syslog('msg') logs message with ident "python".

[R. David Murray]

R. David Murray  added the comment:

One argument in favor of letting openlog pick it (assuming it uses argv[0]) is 
that for a while at least we will have many systems running both python2 and 
python3, and it might be useful to have that distinction show up in the log if 
the fallback is used.  I'm not sure this is a strong argument :)

--

___
Python tracker 

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

[issue8484] ssl socket with certificate verification fails on SHA256 digest algorithm

[Beda Kosata]

New submission from Beda Kosata :

When trying a secure connection to an HTTPS server with server certificate 
verification, I get very strange behaviour when the digest used in the signing 
certificate is SHA-256 (+RSA).
On Windows with Python 2.6.4 or 2.6.5, I consistently get the following error:

ssl.SSLError: [Errno 1] _ssl.c:480: error:0D0C50A1:asn1 encoding 
routines:ASN1_item_verify:unknown message digest algorithm

When I tried to reproduce this on Ubuntu Linux, I found that it either failed 
with the same error or succeeded in case the hashlib was imported before the 
actual code. I got the same behaviour on Gentoo Linux with Python 2.6.4 and 
Fedora 11 and Debian unstable with other versions of Python 2.6.
On Windows, importing hashlib prior to the code does not fix it as is does on 
Linux.

Using openssl s_client (openssl s_client -connect sha256.tbs-internet.com:443 
-CAfile chain.pem) give no error, so the problem is not directly with openssl.
It seems that the Python ssl (_ssl) library does not load properly the 
corresponding hash modules from openssl or something like this.

I attach a sample script with the hashlib import commented out. I also add a 
pem file with certificates needed for the code to check the server certificate.

P.S.- I was able to reproduce the same behaviour with another site using 
SHA-256 base digests.

--
components: Library (Lib)
files: ssl_check.py
messages: 103823
nosy: beda
severity: normal
status: open
title: ssl socket with certificate verification fails on SHA256 digest algorithm
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file17021/ssl_check.py

___
Python tracker 

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

[issue8484] ssl socket with certificate verification fails on SHA256 digest algorithm

[Beda Kosata]

Changes by Beda Kosata :


Added file: http://bugs.python.org/file17022/chain.pem

___
Python tracker 

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

[issue8482] test_gdb - "(unable to read python frame information)" mismatch

[STINNER Victor]

STINNER Victor  added the comment:

> The test actually runs fine under "./configure --with-pydebug" (...)

I changed configure to disable all compiler optimisations if --with-pydebug is 
used. Retry with ./configure CFLAGS="-O0".

A variable may be optimized (use a register instead a variable allocated on the 
stack) and gdb is unable to get its value. If we are able to isole the 
variable, you could try to ask gcc to not optimize it... but only if it doesn't 
change Python performances too much.

Another simple approach is to disable the test if Python was compiled with 
compiler optimisation. To detect optimization, we should use a gdb batch script 
trying to read the optimized (or not) variable.

--

___
Python tracker 

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

[issue8484] ssl socket with certificate verification fails on SHA256 digest algorithm

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +giampaolo.rodola, janssen, pitrou
priority:  -> normal
type: crash -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue4256] optparse: provide a simple way to get a programmatically useful list of options

[R. David Murray]

R. David Murray  added the comment:

I prefer an approach that allows this option to be defined by default, since if 
it is not defined by default it defeats part of the purpose of having the 
option.  The program author may not be concerned with completions (or even know 
about them), but if the option is defined by default then even the programs of 
those authors can be auto-completed by the generic script.

--

___
Python tracker 

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

[issue4256] optparse: provide a simple way to get a programmatically useful list of options

[R. David Murray]

R. David Murray  added the comment:

Removing 2.7 since it is now in feature freeze.

--
versions:  -Python 2.7

___
Python tracker 

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

[issue8483] asyncore.dispatcher.__repr__() is weird

[Giampaolo Rodola']

Changes by Giampaolo Rodola' :


--
nosy: +giampaolo.rodola

___
Python tracker 

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

[issue8484] ssl socket with certificate verification fails on SHA256 digest algorithm

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Changing OpenSSL initialization to the following seems to fix the issue (with 
OpenSSL 0.9.8k and 1.0.0):

/* Init OpenSSL */
SSL_load_error_strings();
SSL_library_init();
#ifdef WITH_THREAD
/* note that this will start threading if not already started */
if (!_setup_ssl_threads()) {
return;
}
#endif
OpenSSL_add_all_algorithms();


_hashopenssl.c might need that code too, therefore I'm adding gps to the nosy 
list.

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

[issue7384] curses crash on FreeBSD

[Stefan Krah]

Stefan Krah  added the comment:

Jeroen, thanks for the idea. I asked Thomas Dickey and he said that
one should not load both libncurses.so and libncursesw.so.

I think this means that if libreadline.so is already linked against
libncurses.so, we are stuck with libncurses.so for the curses module.


If this affects users who want the wide character version, they could
file a bug report with their distro:

Thomas Dickey pointed out that there are two ways for a distro to
deal with this problem:

  1) Link libreadline against ncursesw.

  2) Split out the termcap interface (which readline uses) as
 libtinfo. This is a configure option for ncurses and SuSE
 and Redhat are doing this.


I'm attaching a new patch against py3k that makes sure that the
readline and curses modules use the same curses library.

(This does not apply to Darwin, but I don't want to touch that logic.)
  

I'm going to test the patch on py3k-cdecimal to see if it works on
the buildbots.

--
stage: needs patch -> patch review
Added file: http://bugs.python.org/file17023/issue7384-3-py3k.patch

___
Python tracker 

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

[issue8485] Don't accept bytearray as filenames, or simplify the API

[STINNER Victor]

New submission from STINNER Victor :

r72313 (PEP 383) created the PyUnicode_FSConverter() function: encode an object 
to a byte string using the default file system encoding. PyBytes and 
PyByteArray are leaved unchanged (just increment the reference counter), 
PyUnicode is encoded to PyBytes (if the encoder produces something else, an 
error is raised).

In my opinion, a file name is a character string (Windows) or a byte string 
(POSIX) and a bytearray object is unexpected. Only few function support this 
type: no function of os.path accept them. In the Python test suite, no function 
use bytearray for filenames.

It's already complex to support 2 types (bytes and str) for filenames in 
os.path, I think that a third type is too much and has no real world use case 
(the module manipuling filenames is os.path and it doesn't support bytearray 
and nobody noticed that).

Suppport bytearray is complex because we need to acquire a lock (using 
PyObject_GetBuffer()) and release the lock 
(o->ob_type->tp_as_buffer->bf_releasebuffer(o, 0)... that's not really 
intuitive...). posixmodule.c uses functions bytes2str() and realease_bytes() to 
handle bytearray easily. But these functions are static and other modules have 
to reimplement them.

I propose the reject bytearray in PyUnicode_FSConverter(), or to simplify the 
API and fix Python to accept bytearray filename everywhere especially in 
os.path.

***

Reject bytearray in PyUnicode_FSConverter() is trivial only there is only one 
test that have to be changed in the whole Python3 test suite: 
test_empty_bytearray in test_bytes.py. This function shows that bytearray is 
complex and introduce subtle bugs (the lock/GIL issue). All code using 
PyUnicode_FSConverter() would become simpler.

Example:


/* Release the lock, decref the object. */
static void
release_bytes(PyObject* o)
{
if (PyByteArray_Check(o))
o->ob_type->tp_as_buffer->bf_releasebuffer(o, 0);
Py_DECREF(o);
}

...
realease_byte(path);


becomes "Py_DECREF(path);" and release_bytes() can be removed.

And

static char*
bytes2str(PyObject* o, int lock)
{
if(PyBytes_Check(o))
return PyBytes_AsString(o);
else if(PyByteArray_Check(o)) {
if (lock && PyObject_GetBuffer(o, NULL, 0) < 0)
/* On a bytearray, this should not fail. */
PyErr_BadInternalCall();
return PyByteArray_AsString(o);
} else {
/* The FS converter should have verified that this
   is either bytes or bytearray. */
Py_FatalError("bad object passed to bytes2str");
/* not reached. */
return "";
}
}

...
path = bytes2str(opath);


becomes "path = PyBytes_AS_STRING(opath);" (or maybe "path = 
PyBytes_AsString(opath);" if you don't trust PyUnicode_FSConverter)  and 
bytes2str() can be removed.

***

Simplify the API means that bytes2str() and release_bytes() should become 
protected functions (not static, but prefixed by "_Py_") or maybe public ("Py_" 
prefix).

But the most complex part is to modify os.path to support bytearray, and this 
task would not be funny :-)

--
components: Interpreter Core, Library (Lib), Unicode
messages: 103829
nosy: haypo
severity: normal
status: open
title: Don't accept bytearray as filenames, or simplify the API
versions: Python 3.2

___
Python tracker 

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

[issue8485] Don't accept bytearray as filenames, or simplify the API

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +loewis

___
Python tracker 

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

[issue8480] test_gdb: No frame is currently selected.

[STINNER Victor]

STINNER Victor  added the comment:

I may be related to #8482 (compiler optimization level?).

--
nosy: +haypo

___
Python tracker 

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

[issue8479] test_gdb: No stack

[STINNER Victor]

STINNER Victor  added the comment:

I may be related to #8482 (compiler optimization level?).

--
nosy: +haypo

___
Python tracker 

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

[issue8485] Don't accept bytearray as filenames, or simplify the API

[STINNER Victor]

STINNER Victor  added the comment:

Patch removing bytearray filename support: it mostly removes code.

--
keywords: +patch
Added file: http://bugs.python.org/file17024/no_bytearray_filename.patch

___
Python tracker 

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

[issue8485] Don't accept bytearray as filenames, or simplify the API

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Or perhaps the bytearray can be converted to a bytes object. This is not 
optimal performance-wise but is unlikely to make a difference in real-world 
code (if you are passing a filename to an external API, chances are some IO 
will occur which will dwarf the cost of creating a separate bytes object).

But I agree that supporting bytearrays in filename-taking functions, while 
"nice" from a consistency point of view, isn't really useful in practice. So I 
would be ok to remove that support if it simplifies (or avoids complexifying) 
the logic for those functions.

--
nosy: +pitrou

___
Python tracker 

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

[issue8483] asyncore.dispatcher.__repr__() is weird

[R. David Murray]

R. David Murray  added the comment:

I'm not clear on what you are finding weird, here.  Your issue title talks 
about __repr__, but your last post talks about __str__.

--
nosy: +r.david.murray
priority:  -> low

___
Python tracker 

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

[issue8486] [PATCH] threading.Event()

[Benjamin VENELLE]

New submission from Benjamin VENELLE :

Hi,

I'm suggesting to declare a __bool__() function as an alias for is_set() in 
Event class from threading package. So Event objects could be used like 
booleans.

Ex:

I thought 'while(not event): do_something()' is much intuitive than 'while(not 
event.is_set()): do_something()'

--
components: Library (Lib)
messages: 103835
nosy: Kain94
severity: normal
status: open
title: [PATCH] threading.Event()
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

___
Python tracker 

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

[issue8483] asyncore.dispatcher.__repr__() is weird

[Dirkjan Ochtman]

Dirkjan Ochtman  added the comment:

David, just have a look at the interpreter transcript, in particular the 
results of the print statements. I'm not sure why it happens, in my previous 
message I just stated a hypothesis.

--

___
Python tracker 

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

[issue8486] [PATCH] threading.Event()

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Due to the nature of an Event, you should in most situations wait() on it, 
rather than test its value. Also, changing the boolean value of an Event would 
break existing code. I therefore think this should be rejected.

--
nosy: +pitrou

___
Python tracker 

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

[issue7384] curses crash on FreeBSD

[Mark Dickinson]

Mark Dickinson  added the comment:

This patch looks good to me, assuming that the buildbots are happy.  I agree 
that this seems like a sensible solution for now, even if it means limiting 
users to ncurses rather than ncursesw.

I was initially a bit surprised that it works on OS X, since OS X doesn't have 
'ldd';  but in that case the os.system call simply outputs "sh: ldd: command 
not found" to stderr and (presumably) nothing to stdout;  no Python exception 
is raised, so it's all okay.  It might be worth adding code to avoid the 
os.system('ldd ...') call on OS X, just to avoid the unnecessary error message 
on the console.  Apart from this, I say +1 to applying the patch.

Many thanks for all the detective work!

--

___
Python tracker 

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

[issue8482] test_gdb - "(unable to read python frame information)" mismatch

[Nick Coghlan]

Nick Coghlan  added the comment:

I'll weight for Dave to weigh in before I dig any further - the problem I am 
seeing seems to have a lot in common with the issue he reported on 64-bit 
Fedora, but I only followed about half of that bug discussion.

--

___
Python tracker 

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

[issue8482] test_gdb - "(unable to read python frame information)" mismatch

[Nick Coghlan]

Changes by Nick Coghlan :


--

___
Python tracker 

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

[issue8482] test_gdb - "(unable to read python frame information)" mismatch

[Nick Coghlan]

Nick Coghlan  added the comment:

I'll wait for Dave to weigh in before I dig any further - the problem I am 
seeing seems to have a lot in common with the issue he reported on 64-bit 
Fedora, but I only followed about half of that bug discussion.

--

___
Python tracker 

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

[issue8486] [PATCH] threading.Event()

[Benjamin VENELLE]

Benjamin VENELLE  added the comment:

Yes, I agree when Event objects are used to sync threads. But in my case, I'm 
using them like signals to terminate some server's thread through a proper way.

This is a just a "cosmetic" stuff to enhance readability.

--

___
Python tracker 

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

[issue8486] [PATCH] threading.Event()

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Yes, I agree when Event objects are used to sync threads. But in my
> case, I'm using them like signals to terminate some server's thread
> through a proper way.

In this case, you don't have to use an Event. A boolean attribute on one
of your objects is enough.
(similarly, you would use a "volatile" variable in C)

--

___
Python tracker 

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

[issue8188] Unified hash for numeric types.

[Mark Dickinson]

Mark Dickinson  added the comment:

> Regarding a hash function for complex types, I think documenting the 
> existing behavior for PyComplex is sufficient. The magic number 103 > 
> could be documented in hash_info as 'multiplier' and _PyHASH_MULTIPLIER. 

Seems reasonable;  I'm tempted to call the constant it hash_info.imaginary and 
_PyHASH_IMAGINARY, though.  :)  

There's also an implicit parameter in this algorithm, namely the size of a C 
long;  I think this should go into sys.hash_info, too.

complex_hash does need fixing in one respect:  it currently depends on signed 
overflow wrapping modulo 2**BIT_IN_LONG, but that's undefined behaviour;  it 
should use unsigned arithmetic instead.

> I think hash(m/P) should preserve sign. It just seems more symmetrical. :)

Agreed.  Along similar lines, I think I'm also going to get rid of _PyHASH_NINF 
and just use -PyHASH_INF instead.

--

___
Python tracker 

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

[issue8486] [PATCH] threading.Event()

[Benjamin VENELLE]

Benjamin VENELLE  added the comment:

> In this case, you don't have to use an Event. A boolean attribute on one
> of your objects is enough.
> (similarly, you would use a "volatile" variable in C)

This is already the case with Event. Look at threading.py @line ~355 Event 
class has a kinda private attribute _flags which is set/unset right before 
notifying. Using a boolean would look almostly the same so why to reinvent the 
wheel ? :)

If you look also at is_set(), it has the same meanings than __bool__() (ie 
returning True or False according to object's status). My suggest is only to 
had the following two lines:

def __bool__(self):
  return self.is_set()

--

___
Python tracker 

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

[issue8480] test_gdb: No frame is currently selected.

[STINNER Victor]

STINNER Victor  added the comment:

libpython.py had a type "PyStringObjectPtr" referencing "PyStringObject" type, 
whereas Python3 uses "PybytesObject". That's why you got this error. It should 
be fixed by r80311 (and r80312).

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

[issue8479] test_gdb in Python3: No stack

[STINNER Victor]

STINNER Victor  added the comment:

The problem is that test_gdb is not compatible with Python3.

test_gdb uses "print x" syntax instead of "print(x)", and "except XXX, xxx:" 
instead of "except XXX as xxx:". Note: "print range(1000)" => 
"print(list(range(1000)))".

DebuggerOutput.run_gdb() should also convert the output to unicode, maybe using 
out = out.decode("ascii"); err = err.decode("ascii");.

--
title: test_gdb: No stack -> test_gdb in Python3: No stack

___
Python tracker 

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

[issue8486] threading.Event()

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Using a boolean would look almostly the same so why to reinvent the
> wheel ? :)

Hmm, /you/ are reinventing the wheel by suggesting to use an Event
instead of a simple boolean. Just loop like this:

while not self.stop_me:
   # etc.

and set the stop_me attribute to True when you want to stop your thread.

--
title: [PATCH] threading.Event() -> threading.Event()

___
Python tracker 

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

[issue7755] copyright clarification for audiotest.au

[VanL]

VanL  added the comment:

However, a 3 second clip used for testing purposes in an open source 
programming language appears to meet the guidelines for fair use in the United 
States. In particular, no one is going to use the test clip as a substitute for 
any part of the Monty Python skit. There is no trading on the content of the 
clip to capture any value whatsoever; it could be a test beep and it would 
serve the same purpose. In short, I think this could go on under fair use 
principles until there was some sort of complaint. 

That said, the content of the sound file really doesn't matter in this 
instance. It could be replaced by a clip of Barry saying "My hovercraft is full 
of eels" and the same functionality would be preserved.

--
nosy: +VanL

___
Python tracker 

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

[issue7755] copyright clarification for audiotest.au

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Shouldn't "My hovercraft is full of eels" be considered an original creation of 
the Monty Python, and as such copyrighted?

--
nosy: +pitrou

___
Python tracker 

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

[issue7755] copyright clarification for audiotest.au

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

Note that guido.au is just him saying some crazy sh*t and I'm fairly certain 
couldn't be construed as copyrighted material (unless Guido is going to assert 
copyright over it :)

--

___
Python tracker 

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

[issue8484] ssl socket with certificate verification fails on SHA256 digest algorithm

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Here is a patch. I'm not really happy about the test because it relies on an 
external test site, and the certificate apparently expires in 2011.

--
keywords: +patch
Added file: http://bugs.python.org/file17025/algos.patch

___
Python tracker 

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

[issue8479] test_gdb in Python3: No stack

[Dave Malcolm]

Dave Malcolm  added the comment:

Issue 8380 contains a port of the code and tests to python 3; it's awaiting 
review.

--
superseder:  -> Port of the gdb7 debugging hooks to the "py3k" branch

___
Python tracker 

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

[issue8479] test_gdb in Python3: No stack

[Dave Malcolm]

Changes by Dave Malcolm :


--
resolution:  -> duplicate
status: open -> closed

___
Python tracker 

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

[issue8480] test_gdb: No frame is currently selected.

[Dave Malcolm]

Dave Malcolm  added the comment:

There was a patch for this attached to issue 8380, and you've fixed things in a 
different way.  Should I regenerate a patch against what's now in SVN, or 
should we use my patch?

--
assignee: dmalcolm -> loewis

___
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

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

There is another inconsistency that this patch does not seem to cure.  With 
patch applied and D and DT defined as in OP,

>>> D(1900,1,1) > DT(1900,1,1)
True

but

>>> DT(1900,1,1) < D(1900,1,1)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: can't compare DT to D

and

>>> date(1900,1,1) < datetime(1900,1,1)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: can't compare datetime.datetime to datetime.date

Note that without the patch,

>>> D(1900,1,1) > DT(1900,1,1)
False

but both behaviors seem to be wrong.

--
nosy: +Alexander.Belopolsky

___
Python tracker 

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

[issue8380] Port of the gdb7 debugging hooks to the "py3k" branch

[Dave Malcolm]

Dave Malcolm  added the comment:

Looking at issue 8480, it looks like this a partial fix was applied, which will 
mean this patch will no longer apply.  Should I regenerate a patch against 
what's now in SVN, or should we use my patch?

--

___
Python tracker 

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

[issue8380] Port of the gdb7 debugging hooks to the "py3k" branch

[Dave Malcolm]

Changes by Dave Malcolm :


--
nosy: +haypo

___
Python tracker 

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

[issue8451] syslog.syslog('msg') logs message with ident "python".

[Eric Smith]

Eric Smith  added the comment:

I have the same reasoning as David, although I was thinking about python vs. 
pythonw. But it's not a big deal.

I think you should check it in as-is, and we can worry about modifying it 
later, if need be.

--

___
Python tracker 

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

[issue8483] asyncore.dispatcher.__repr__() is weird

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

I think the problem relies in here:

# cheap inheritance, used to pass all other attribute
# references to the underlying socket object.
def __getattr__(self, attr):
return getattr(self.socket, attr)

I wonder why this has been added in the first place.
It also causes confusing error messages when accessing undefined attributes:

>>> class B(asyncore.dispatcher):
... def __init__(self, *args):
... asyncore.dispatcher.__init__(self, *args)
...
>>> b = B()
>>> b.blabla
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.6/asyncore.py", line 394, in __getattr__
return getattr(self.socket, attr)
AttributeError: '_socketobject' object has no attribute 'blabla'
>>>

--

___
Python tracker 

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

[issue8380] Port of the gdb7 debugging hooks to the "py3k" branch

[STINNER Victor]

STINNER Victor  added the comment:

> Looking at issue 8480, it looks like this a partial fix was applied,

Martin fixed calls to assertListing(). I renamed PyStringObjectStr to 
PyBytesStringPtr and used a breakpoint on textiowrapper_write() instead of 
PyObject_Dump(). Your patch uses a breakpoint on builtin_id(): I don't know 
what's best, I only tried to fix tests.

Sorry, I didn't knew this issue.

> which will mean this patch will no longer apply.  Should I regenerate
> a patch against what's now in SVN, or should we use my patch?

I think that I would be easier to update your patch to SVN (py3k).

--

I don't understand why the tests contain long type "L" suffix and unicode "u" 
prefix (eg. "1L"). Is it because gdb is linked to Python2?

--

___
Python tracker 

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

[issue8380] Port of the gdb7 debugging hooks to the "py3k" branch

[Dave Malcolm]

Dave Malcolm  added the comment:

Thanks; I'm working on a newer version of the patch based on what's in SVN.  

I prefer your choice of breakpoint, and I've changed my mind about the python2 
vs python3 proxyval handling.  Hope to have a fresh patch later today.

--

___
Python tracker 

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

[issue8487] os.mknod() fails on NFS mounted directories

[Nikolaus Rath]

New submission from Nikolaus Rath :

$ cat test.py
#!/usr/bin/env python
import os
import stat
dbfile = './testfile.test'
with open(dbfile, 'w') as fh:
print('Opened file for writing')
os.unlink(dbfile)
os.mknod(dbfile, stat.S_IRUSR | stat.S_IWUSR | stat.S_IFREG)
print('Mknod\'ed file')

[cl...@ih ~]$ cd tmp  <-- nfs mounted on a 64bit Fedora box
[cl...@ih tmp]$ ~/tmp/test.py
Opened file for writing
Traceback (most recent call last):
  File "/home/cliff/tmp/test.py", line 9, in 
os.mknod(dbfile, stat.S_IRUSR | stat.S_IWUSR | stat.S_IFREG)
OSError: [Errno 2] No such file or directory

[cl...@ih tmp]$ cd /tmp   <-- locally mounted on a HD
[cl...@ih tmp]$ ~/tmp/test.py
Opened file for writing
Mknod'ed file


I think the mknod() call really shouldn't fail if it tries to create an 
ordinary file that can be created with open() with problems.

--
components: IO
messages: 103860
nosy: Nikratio
severity: normal
status: open
title: os.mknod() fails on NFS mounted directories
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

[issue8483] asyncore.dispatcher.__repr__() is weird

[R. David Murray]

R. David Murray  added the comment:

I somehow missed the fact that B was a dispatcher subclass.  Too early in my 
morning, I guess.

So, I think the title of this issue should be "asyncore.dispatcher's __repr__ 
not being used as fallback for __str__", and your speculation looks likely to 
be on target, as Giampaolo says.

Unfortunately, even if forwarding everything to the socket is questionable, it 
would probably be a really bad idea to change it, since there is likely code in 
the field depending on this behavior.

The specific case of __str__ could be fixed by adding an __str__ to dispatcher, 
and that would be a lot less likely to break anything other than perhaps the 
odd doctest here and there (but that would mean it still shouldn't be changed 
in 2.6).

--

___
Python tracker 

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

[issue8484] ssl socket with certificate verification fails on SHA256 digest algorithm

[Antoine Pitrou]

Antoine Pitrou  added the comment:

After several attempts, I've failed generating a self-signed certificate that 
would reproduce the issue without relying on an external server. Perhaps 
there's something else than simply the hashing algorithm. In any case I think 
I'm simply gonna keep the current patch.

--

___
Python tracker 

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

[issue8486] threading.Event()

[R. David Murray]

R. David Murray  added the comment:

This is a duplicate of #5998, which was rejected.

--
nosy: +r.david.murray
priority:  -> normal
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Add __bool__ to threading.Event and multiprocessing.Event

___
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

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Upon further reflection I am -1 on this patch.  First, as implemented this 
patch changes behavior of an explicit invocation of date.__eq__.  The patch 
proposes to remove the following tests:

-# Neverthelss, comparison should work with the base-class (date)
-# projection if use of a date method is forced.
-self.assert_(as_date.__eq__(as_datetime))
-different_day = (as_date.day + 1) % 20 + 1
-self.assert_(not as_date.__eq__(as_datetime.replace(day=
- different_day)))

Second, the patch introduces dependence of the baseclass method 
(date_richcompare) on a particular subclass (PyDateTime_Check).  This is 
against OOP principles.

I am not sure how the "equality not symmetric" issue can be fixed.  In my 
opinion current datetime implementation is fighting OOP and violating the 
substitution principle in an attempt to prevent date to datetime comparison.  I 
would prefer seeing one of two things: either datetime not inheriting from date 
or making datetime to date comparison compare date part alone.  Once you stop 
fighting OOP principles, symmetry of equality for subclasses will follow from 
that for the base class automatically.

Given that either of these solutions means a major change, I think it is best 
to leave the things as they are now.

--

___
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

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +mark.dickinson

___
Python tracker 

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

[issue8487] os.mknod() fails on NFS mounted directories

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Well, this looks like a filesystem problem more than a Python problem.
The error (errno 2) comes from the mknod() system call itself.

--
nosy: +pitrou

___
Python tracker 

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

[issue8487] os.mknod() fails on NFS mounted directories

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +exarkun

___
Python tracker 

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

[issue8483] asyncore.dispatcher.__repr__() is weird

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

> Unfortunately, even if forwarding everything to the socket is 
> questionable, it would probably be a really bad idea to change it, 
> since there is likely code in the field depending on this behavior.

I agree, even if it would break a code which is fundamentally *already* wrong. 
Maybe we can do this in 2.7 and 3.2 only?
The AttributeError message is *very* confusing.
Actually I've seen it a lot of times through the years and never figured out it 
had to do with that weird __getattr__ statement.

--

___
Python tracker 

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

[issue8478] tokenize.untokenize first token missing failure case

[rb]

Changes by rb :


--
type:  -> behavior

___
Python tracker 

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

[issue2706] datetime: define division timedelta/timedelta

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Can someone (Mark?) add an acknowledgment for Victor Stinner to the NEWS file?  
My py3k patch was 90% code from Victor's trunk patch.

--

___
Python tracker 

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

[issue1673409] datetime module missing some important methods

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

With issue2706 accepted, I think this issue can now be rejected because 
proposed td.tosecs() can now be spelled simply as td/timedelta(seconds=1).

The other RFE for a totimestamp() method is a duplicate of issue2736.

--
nosy: +Alexander.Belopolsky, mark.dickinson -belopolsky

___
Python tracker 

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

[issue4256] optparse: provide a simple way to get a programmatically useful list of options

[Steven Bethard]

Steven Bethard  added the comment:

On Wed, Apr 21, 2010 at 12:36 AM, Andy Buckley  wrote:
> Or to add the option just before arg parsing, if it has not already been 
> defined?

Something like this was suggested before and it doesn't really work
out well. It means the first time you call .parse_args(), your options
get modified. So if you do anything with the parser before
.parse_args() -- for example, calling .print_help() -- then you don't
get the right options.

On Wed, Apr 21, 2010 at 5:12 AM, R. David Murray  wrote:
> I prefer an approach that allows this option to be defined by default

I agree that it would be best if all command line utilities supported
this by default[1]. I'm just not sure how to do it in a backwards
compatible way. The fact that the most recent patch against argparse
has to modify so many test cases suggests that it's going to have
unexpected consequences for a bunch of users.

[1] Though I'd feel more confident in that belief if someone could
point me to what the output of other programs that do this looks like
so that I could see we were following a standard somewhere.

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus

--

___
Python tracker 

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

[issue8483] asyncore.dispatcher's __getattr__ method produces confusing effects

[R. David Murray]

R. David Murray  added the comment:

Well, the attribute error message could be fixed, too, by enclosing the 
forwarding getattr in a try/except and generating the "correct" attribute error 
text.

Changing the forwarding behavior itself is the kind of issue that would need to 
be discussed on python-dev, and we'd need to make sure that the various 
asyncore constiuencies got a chance to chime in (remember the previous breakage 
of asyncore monkey-patching in 2.6 and the rancor it caused).  My guess is that 
we can't change it, though.  Certainly not in 2.7.

I'm changing the title of the issue to more accurately reflect the discussion.

--
priority: low -> normal
title: asyncore.dispatcher.__repr__() is weird -> asyncore.dispatcher's 
__getattr__ method produces confusing effects

___
Python tracker 

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

[issue8487] os.mknod() fails on NFS mounted directories

[Charles-Francois Natali]

Charles-Francois Natali  added the comment:

> Well, this looks like a filesystem problem more than a Python problem.
The error (errno 2) comes from the mknod() system call itself.

Definitely.

@Nikratio
Just to be sure, could you provide the result of:
- strace ~/tmp/test.py from NFS-mounted directory
- the relevant line of "mount" output
- "nfsstat -a" on client (and maybe server)

But you should know that mknod is disabled on some NFS servers for security 
reasons, and see man mknod:
"   POSIX.1-2001 says: "The only portable use of mknod() is to create a 
FIFO-
   special file.  If mode is not S_IFIFO or dev is not 0, the behavior of 
mknod()
   is unspecified."  However, nowadays one should never use mknod() for this
   purpose; one should use mkfifo(3), a function especially defined for this
   purpose.

   Under Linux, this call cannot be used to create directories.  One should 
make
   directories with mkdir(2).

   There are many infelicities in the protocol underlying NFS.  Some of 
these
   affect mknod()."

So try to avoid mknod over NFS...

--
nosy: +neologix

___
Python tracker 

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

[issue2706] datetime: define division timedelta/timedelta

[Mark Dickinson]

Mark Dickinson  added the comment:

Ah, yes.  Sorry, Victor!  There's actually no acknowledgement in Misc/NEWS:  
it's not *that* common to put acknowledgements there, and I'm not sure it's 
necessary here, but I've fixed the commit message.

--

___
Python tracker 

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

[issue8483] asyncore.dispatcher's __getattr__ method produces confusing effects

[R. David Murray]

R. David Murray  added the comment:

By the way, the __getattr_ was in the very first version of the code checked in 
to the repository.  I think the chances of removing it are pretty much zero :)

--

___
Python tracker 

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

[issue1673409] datetime module missing some important methods

[Mark Dickinson]

Mark Dickinson  added the comment:

Closing this as a duplicate of issue 2736, as suggested.  I'll combine the nosy 
lists.

(BTW, as well as the newly introduced division methods, td.tosecs already 
exists, except that it's spelt td.total_seconds.)

--
resolution:  -> duplicate
status: open -> closed
superseder:  -> datetime needs an "epoch" method

___
Python tracker 

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

[issue2736] datetime needs an "epoch" method

[Mark Dickinson]

Mark Dickinson  added the comment:

Close issue 1673409 as a duplicate of this one;  combining nosy lists.

--
nosy: +catlee, erik.stephens, guettli, jribbens, mark.dickinson, pitrou, 
skip.montanaro, srittau, steve.roberts, tim_one, tomster

___
Python tracker 

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

[issue4256] optparse/argparse: provide a simple way to get a programmatically useful list of options

[Éric Araujo]

Éric Araujo  added the comment:

Hello

Here’s another approach, which has to be used explicitly but provides much more 
flexible completion: http://pypi.python.org/pypi/optcomplete

I ask the author some time ago if he’d adapt it to argparse; he answered he 
wouldn’t have time but it shouldn’t be too hard. It’s 221 lines of code 
(according to sloccount), perhaps worth merging into argparse.

Regards

--
nosy: +merwok
title: optparse: provide a simple way to get a programmatically useful list of 
options -> optparse/argparse: provide a simple way to get a programmatically 
useful list of options

___
Python tracker 

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

[issue2736] datetime needs an "epoch" method

[Mark Dickinson]

Changes by Mark Dickinson :


--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue8487] os.mknod() fails on NFS mounted directories

[Georg Brandl]

Georg Brandl  added the comment:

Closing this, as it is not an issue with Python.

--
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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

[issue1673409] datetime module missing some important methods

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Wed, Apr 21, 2010 at 2:03 PM, Mark Dickinson  wrote:
..
> (BTW, as well as the newly introduced division methods, td.tosecs already 
> exists, except that it's spelt td.total_seconds.)

Aggrrr!  How did that slip in? :-)

8639913600.0

Shouldn't td.total_seconds() return Decimal?  Maybe in py4k ...

--

___
Python tracker 

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

[issue8478] tokenize.untokenize first token missing failure case

[Georg Brandl]

Changes by Georg Brandl :


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

___
Python tracker 

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

[issue8483] asyncore.dispatcher's __getattr__ method produces confusing effects

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

You're absolutely right.
Patch in attachment.

--
keywords: +patch
Added file: http://bugs.python.org/file17026/asyncore.patch

___
Python tracker 

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

[issue8488] Docstrings of non-data descriptors "ignored"

[Torsten Landschoff]

New submission from Torsten Landschoff :

[I would assign priority minor to this, but the tracker won't let me]

I really like the online documentation features of python. However, I wonder 
about the output of the following simple example:

class Descriptor(object):
"""Doc of a non-data descriptor."""
def __get__(self, instance, owner):
return 42 if instance else self

class GetSetDescriptor(Descriptor):
"""Doc of a data-descriptor."""
def __set__(self, instance, value):
pass

class Demo(object):
non_data = Descriptor()
data = GetSetDescriptor()

help(Demo)


This results in

Help on class Demo in module __main__:

class Demo(builtins.object)
 |  Methods defined here:
 |  
 |  non_data = <__main__.Descriptor object>
 |  --
 |  Data descriptors defined here:
 |  
 |  __dict__
 |  dictionary for instance variables (if defined)
 |  
 |  __weakref__
 |  list of weak references to the object (if defined)
 |  
 |  data
 |  Doc of a data-descriptor.


I think the behaviour of pydoc wrt. the non_data descriptor is a bit out of 
line. I would have expected to find the docstring in the output here.

--
components: Library (Lib)
files: doc.py
messages: 103880
nosy: torsten
severity: normal
status: open
title: Docstrings of non-data descriptors "ignored"
type: behavior
versions: Python 2.5, Python 2.6, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17027/doc.py

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

Jess Austin  added the comment:

To be systematic, without the patch:

>>> D(1900, 1, 1) > DT(1900, 1, 1)
False
>>> D(1900, 1, 1) < DT(1900, 1, 1)
False
>>> DT(1900, 1, 1) > D(1900, 1, 1)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: can't compare DT to D
>>> DT(1900, 1, 1) < D(1900, 1, 1)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: can't compare DT to D


with the patch:

>>> D(1900, 1, 1) > DT(1900, 1, 1)
True
>>> D(1900, 1, 1) < DT(1900, 1, 1)
False
>>> DT(1900, 1, 1) > D(1900, 1, 1)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: can't compare DT to D
>>> DT(1900, 1, 1) < D(1900, 1, 1)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: can't compare DT to D


It might seem like the latter behavior is marginally better, but really this is 
just a mess, since a date-datetime comparison TypeErrors in all directions.  I 
appreciate Alexander's more experienced perspective, but it's not obvious to me 
that this problem is insoluble simply due to OOP algebra.  I'm going to keep 
tinkering with this to see if there isn't a way to satisfy his concerns AND fix 
these bugs WITHOUT breaking the established (and admittedly anti-OOP) behavior 
that dates are not equal to datetimes.

(Incidentally, the test I removed still seems to be an arbitrary ad-hoc 
requirement that subclasses of date behave differently than date itself.  I 
don't see how one could rely on this given the other inconsistencies with date 
subclasses, and so violating this in order to fix more serious problems seems 
acceptable.)

I'm reminded of the set and frozenset situation, which seems almost dual to 
this one.  set and frozenset don't inherit from each other, but they do 
compare.  This seems to bite you only when you try to redefine comparison in 
subclasses.

--

___
Python tracker 

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

[issue8482] test_gdb - "(unable to read python frame information)" mismatch

[Martin v . Löwis]

Changes by Martin v. Löwis :


--
assignee:  -> dmalcolm

___
Python tracker 

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

[issue8484] ssl socket with certificate verification fails on SHA256 digest algorithm

[Martin v . Löwis]

Martin v. Löwis  added the comment:

That patch makes no sense. According to SSL_library_init(3SSL),

"OpenSSL_add_ssl_algorithms() and SSLeay_add_ssl_algorithms() are synonyms for 
SSL_library_init()"

So it shouldn't really matter which of these you call, and it should be 
sufficient to call only one of them (or the documentation is incorrect).

--
nosy: +loewis

___
Python tracker 

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

[issue8485] Don't accept bytearray as filenames, or simplify the API

[Martin v . Löwis]

Martin v. Löwis  added the comment:

I'm in favor of removing that support, too, but please check with python-dev 
whether anybody thinks a proper deprecation cycle (deprecated in 3.2, removed 
in 3.3) is needed.

--

___
Python tracker 

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

[issue8314] test_ctypes fails in test_ulonglong on sparc buildbots

[Mark Dickinson]

Mark Dickinson  added the comment:

I was going to say that I think that this issue can be closed now...

... but the src/sparc/v8.S file still looks wrong to me:  Martin fixed one 
missing FFI_TYPE_UINT64 case, but it looks to me as though there's another one, 
in ffi_call_v8.  The code starting at line 68 in that file looks like:

cmp %i3, FFI_TYPE_INT
be,adone
st  %o0, [%i4]  ! (delay)

cmp %i3, FFI_TYPE_FLOAT
be,adone
st  %f0, [%i4+0]! (delay)

cmp %i3, FFI_TYPE_DOUBLE
be,adouble
st  %f0, [%i4+0]! (delay)

cmp %i3, FFI_TYPE_SINT8
be,asint8
sll %o0, 24, %o0! (delay)

cmp %i3, FFI_TYPE_UINT8
be,auint8
sll %o0, 24, %o0! (delay)

cmp %i3, FFI_TYPE_SINT16
be,asint16
sll %o0, 16, %o0! (delay)

cmp %i3, FFI_TYPE_UINT16
be,auint16
sll %o0, 16, %o0! (delay)

cmp %i3, FFI_TYPE_SINT64
be,alonglong
st  %o0, [%i4+0]! (delay)
done:
ret
restore

Shouldn't there should be another block here for FFI_TYPE_UINT64, essentially 
identical to the FFI_TYPE_SINT64 block?  Or am I missing something?

I don't know why this omission doesn't cause buildbot failures; perhaps it's 
because the compiled test function (e.g., tf_Q in _ctypes_test.c) just happens 
to already have placed the correct values in the right locations ([%i4 + 0] and 
[%i4 + 4]) already, before transferring them to o0 and o1.

I've asked about this on the libffi-discuss mailing list, as a follow-up to 
Victor's report there.

--

___
Python tracker 

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

[issue8465] Backreferences vs. escapes: a silent failure solved

[Georg Brandl]

Changes by Georg Brandl :


--
assignee:  -> pitrou
nosy: +pitrou

___
Python tracker 

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

[issue7332] python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule

[Kees Cook]

Kees Cook  added the comment:

The stack protector will add 8 (aligned, so possibly padded) bytes to each 
stack frame of functions with arrays of 8 or greater bytes.  So if things are 
marginal, this could make the difference between Pythons compiled with/without 
-fstack-protector.

N.B. if rPath is compiled with -D_FORTIFY_SOURCE=2 and -O1, then 
-D_FORTIFY_SOURCE=2 has no effect (it is only activated at -O2 or higher).

Details on Ubuntu's compiler flag defaults:
https://wiki.ubuntu.com/CompilerFlags

Putting MAXPATH on the stack certainly seems like a big waste of space, though. 
 :)

--
nosy: +keescook

___
Python tracker 

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

[issue8465] re: Backreferences vs. escapes: a silent failure solved

[STINNER Victor]

Changes by STINNER Victor :


--
title: Backreferences vs. escapes: a silent failure solved -> re: 
Backreferences vs. escapes: a silent failure solved

___
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

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Wed, Apr 21, 2010 at 2:33 PM, Jess Austin  wrote:
..
> It might seem like the latter behavior is marginally better, but really this 
> is just a mess, since a date-datetime comparison TypeErrors in all
> directions.  I appreciate Alexander's more experienced perspective, but it's 
> not obvious to me that this problem is insoluble simply due to OOP
> algebra.  I'm going to keep tinkering with this to see if there isn't a way 
> to satisfy his concerns AND fix these bugs WITHOUT breaking the
> established (and admittedly anti-OOP) behavior that dates are not equal to 
> datetimes.
>

I certainly don't have a proof that this is impossible, so best of
luck.  Note, however that the problematic behavior is due to D/DT
classes implementor's choice not to derive DT from D.  Whether
resulting violation of the symmetry of equality is a bug in python or
D/DT implementation is at least an open question.

--

___
Python tracker 

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

[issue8484] ssl socket with certificate verification fails on SHA256 digest algorithm

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> "OpenSSL_add_ssl_algorithms() and SSLeay_add_ssl_algorithms() are
> synonyms for SSL_library_init()"

The patch calls OpenSSL_add_all_algorithms(), though.
(yes, it's a different one :-))
http://www.openssl.org/docs/crypto/OpenSSL_add_all_algorithms.html

--

___
Python tracker 

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