[issue3766] socket.socket.recv broken (unbearably slow)

[Thorben]

Thorben <[EMAIL PROTECTED]> added the comment:

That's more like it. Now I'd like to see the same behavior on Linux...

2008/9/12 Gabriel Genellina <[EMAIL PROTECTED]>:
>
> Gabriel Genellina <[EMAIL PROTECTED]> added the comment:
>
> I've tested it on Windows XP. MSG_WAITALL is not supported, but I
> replaced it using a while loop. I didn't notice any extraneous delay.
>
> 500 packets @ 2 tokens each (500 very short lists)
> 0.140999794006
> 16008 function calls in 0.146 CPU seconds
>
>   Ordered by: internal time
>
>   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
> 15000.0360.0000.0360.000 {method 'recv' of
> '_socket.socket'
>  objects}
> 15000.0330.0000.0330.000 :1(sendall)
> 15000.0160.0000.0650.000 Client.py:15(read_int)
> 15000.0150.0000.0530.000 Client.py:7(send_int)
>  5000.0090.0000.0770.000
> Client.py:22(read_int_list)
>  5000.0070.0000.0600.000
> Client.py:10(send_int_list)
> 15000.0070.0000.0100.000 struct.py:77(unpack)
> 15000.0050.0000.0050.000 struct.py:54(pack)
>  5000.0040.0000.1410.000 Client.py:31(spam)
> 20010.0040.0000.0040.000 {len}
>10.0030.0030.1460.146 runme.py:11(bench)
> 15000.0030.0000.0030.000 {method 'unpack' of
> 'Struct' objec
> ts}
> 10010.0030.0000.0030.000 {range}
> 10000.0020.0000.0020.000 {method 'append' of
> 'list' objects
> }
>10.0000.0000.0000.000 struct.py:35(_compile)
>20.0000.0000.0000.000 {time.time}
>10.0000.0000.1460.146 :1()
>10.0000.0000.0000.000 {method 'disable' of
> '_lsprof.Prof
> iler' objects}
>
>
> None
> 
>
>
> 1 packet @ 5 tokens (1 very long list)
> 4.8913242
> 450019 function calls in 4.893 CPU seconds
>
>   Ordered by: internal time
>
>   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
>500011.2120.0001.2120.000 :1(sendall)
>500011.0620.0001.0620.000 {method 'recv' of
> '_socket.socket'
>  objects}
>500010.5940.0002.2820.000 Client.py:15(read_int)
>500010.5170.0001.9820.000 Client.py:7(send_int)
>10.3540.3542.7322.732
> Client.py:22(read_int_list)
>500010.3350.0000.5240.000 struct.py:77(unpack)
>500010.2530.0000.2530.000 struct.py:54(pack)
>500010.1890.0000.1890.000 {method 'unpack' of
> 'Struct' objec
> ts}
>10.1760.1762.1582.158
> Client.py:10(send_int_list)
>500020.1020.0000.1020.000 {len}
>50.0970.0000.0970.000 {method 'append' of
> 'list' objects
> }
>20.0020.0010.0020.001 {range}
>10.0020.0024.8934.893 runme.py:19(bench2)
>10.0000.0004.8904.890 Client.py:31(spam)
>20.0000.0000.0000.000 {time.time}
>10.0000.0004.8934.893 :1()
>10.0000.0000.0000.000 {method 'disable' of
> '_lsprof.Prof
> iler' objects}
>
> --
> nosy: +gagenellina
>
> ___
> Python tracker <[EMAIL PROTECTED]>
> 
> ___
>

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3842] can't run close through itertools.chain on inner generator

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

You somehow must tell the iterator that you are done with it.
This is best done by a "del c" in your first snippet, since c is the
last reference to the iterator. 
To do this in a function (or a context manager), the trick is to wrap
the map() iterator inside a generator function.

def wrapiterator(it):
for x in it:
yield x

Then your sample becomes:
>>> with closing(wrapiterator(chain.from_iterable(
...  map(gen, (1,2,3) as c:
...next(c)


Which of course can be rewritten as:

def closingiterator(it):
def wrapper():
for x in it:
yield x
return closing(wrapper())

>>> with closingiterator(chain.from_iterable(map(gen, (1,2,3) as c:
...next(c)


This works because the only reference to the map() iterator is held by
the wrapper generator function. Calling its close() method will
terminate the function, delete its locals, ultimately call the
deallocator of the gen() iterator, which will fire the "finally" block.

Your proposal implies that all c-based iterators need to grow a "close"
method. This is not practical, and is best simulated with this wrapper
generator: close()ing the wrapper will (recursively) destroy the iterators.
If this also works for you, I suggest to close this issue.

--
nosy: +amaury.forgeotdarc
resolution:  -> works for me
status: open -> pending

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3783] dbm.sqlite proof of concept

[Skip Montanaro]

Skip Montanaro <[EMAIL PROTECTED]> added the comment:

Josiah> I know that no one hear likes my particular implementation
Josiah> (though it offers more or less the full interface)...

I think implementing as much of the bsddb interface as you can is fine.  I
agree people used first, next, last, etc and having them present is a good
idea.  My initial aim was to get a replacement for use with shelve.  Its
limitations shouldn't deter people from extending it (or the other dbm.*
modules) in other ways.

Even if all the modules aren't going to be widely cross-platform I see no
reason they can't strive to be more-or-less API-compatible.

Skip

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3657] pickle can pickle the wrong function

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

I'm not sure that pickling random.random is a good idea; did you try to
pickle the random.seed function?
Their definition look very similar (at the end of random.py:
   _inst = Random()
   seed = _inst.seed
   random = _inst.random
) but Random.seed is a python method, whereas Random.random is inherited
from _randommodule.c.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3657] pickle can pickle the wrong function

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

The explanation is actually simple, do not blame bsddb :-)

random.random is a built-in method, so its __module__ attribute is not
set. To find it, pickle.whichmodule loops through all sys.modules, and
pick the first one that contains the function.

I reproduced the problem with a simple file:
# someModule.py
from random import random

then, start python and:
>>> import someModule, random, pickle
>>> pickle.dumps(random.random, 0)
'csomeModule\nrandom\np0\n.'

You may have to change the name of "someModule", to be sure that it
appears before "random" in sys.modules. Tested on Windows and x86_64 Linux.

To correct this, one direction would be to search only built-in or
extension modules; for bound methods (random.random.__self__ is not
None), try to dump separately the instance and the method name (but
getattr(random._inst, 'random') is not random.random).
Or simply change the test...

--
nosy: +amaury.forgeotdarc

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3845] memory access before short string when checking suffix

[Matthias Klose]

New submission from Matthias Klose <[EMAIL PROTECTED]>:

forwarded from https://launchpad.net/bugs/234798

Bug reporter writes:

Python/pythonrun.c's PyRun_SimpleFileExFlags() assumes the filename's
extension
starts four characters back from the end. But what if the filename is
only one
character long? Memory before the filename is referenced which is probably
outside the memory allocated for the string. Here's the relevant bits of
code,
boring lines deleted.

int
PyRun_SimpleFileExFlags(FILE *fp, const char *filename, int closeit,
PyCompilerFlags *flags)
{
ext = filename + strlen(filename) - 4;
if (maybe_pyc_file(fp, filename, ext, closeit)) {
if (strcmp(ext, ".pyo") == 0)
Py_OptimizeFlag = 1;
}

static int
maybe_pyc_file(FILE *fp, const char* filename, const char* ext, int
closeit)
{
if (strcmp(ext, ".pyc") == 0 || strcmp(ext, ".pyo") == 0)
return 1;
}

A trivial solution is:

len = strlen(filename);
ext = filename + len - len > 4 ? 4 : 0;

This will make ext point to the NUL terminator unless filename has room
for the desired /\.py[co]$/ suffix *and* at least one character
beforehand, since I don't suppose it's intended that ".pyo" is a valid
pyo file.

--
components: Interpreter Core
messages: 73083
nosy: doko
severity: normal
status: open
title: memory access before short string when checking suffix
versions: Python 2.5, Python 2.6

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3774] tkinter Menu.delete bug

[Dan OD]

Dan OD <[EMAIL PROTECTED]> added the comment:

Please forgive my rookie bug filing:

I'm getting this bug / crash sometimes when Menu.delete() is called too

It seems to be because self.index( ) sometimes returns None which is of 
course un-iterable and delete() tries to iterate through it:

for i in range(self.index(index1), self.index(index2)+1):

As a fix the previous (simpler) delete works for me, but I don't 
understand the purpose of the extra self.deletecommand() code appended 
so I'm probably missing something.

My crash:
  File "C:\CCPN\ccpn\python\memops\gui\Menu.py", line 127, in 
deleteMenuItems
self.delete(0, Tkinter.END)
  File "C:\Python26\lib\lib-tk\Tkinter.py", line 2665, in delete
for i in range(self.index(index1), self.index(index2)+1):
TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'

--
nosy: +indiedan

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1651995] sgmllib _convert_ref UnicodeDecodeError exception, new in 2.5

[Barry A. Warsaw]

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:


___
Python tracker <[EMAIL PROTECTED]>

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

[issue1651995] sgmllib _convert_ref UnicodeDecodeError exception, new in 2.5

[Barry A. Warsaw]

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:


--
versions: +Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1651995] sgmllib _convert_ref UnicodeDecodeError exception, new in 2.5

[Barry A. Warsaw]

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:


--
priority: normal -> high
versions: +Python 2.6

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3774] tkinter Menu.delete bug

[Hirokazu Yamamoto]

Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment:

>for i in range(self.index(index1), self.index(index2)+1):

Probably your working copy is bit old. Please try latest file.
This issue was fixed in r65971. :-)

# I've added nosy list from issue1342811.

--
nosy: +benjamin.peterson, gpolo, loewis, schuppenies, svenil

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3846] sqlite3 module: Improved concurrency

[Gerhard Häring]

New submission from Gerhard Häring <[EMAIL PROTECTED]>:

I'd really like this change to get into Python 2.6. It's pretty trivial
(just releases the GIL when compiling SQLite statements), but improves
concurrency for SQLite. This means less "database is locked" errors for
our users.

Could somebody please review this and give me an ok to check it in?

--
assignee: ghaering
files: sqlite_concurrency_prepare.diff
keywords: patch
messages: 73086
nosy: ghaering
severity: normal
status: open
title: sqlite3 module: Improved concurrency
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file11473/sqlite_concurrency_prepare.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3846] sqlite3 module: Improved concurrency

[Gerhard Häring]

Changes by Gerhard Häring <[EMAIL PROTECTED]>:


--
keywords: +needs review -patch
priority:  -> high

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3847] Begging for review

[Gerhard Häring]

New submission from Gerhard Häring <[EMAIL PROTECTED]>:

Could one of you please give me a review for the trivial patch at 
http://bugs.python.org/issue3846  It releases the GIL around 
sqlite3_prepare calls to improve concurrency.

Many thanks

-- Gerhard

--
files: unnamed
messages: 73087
nosy: ghaering, josiah.carlson
severity: normal
status: open
title: Begging for review
Added file: http://bugs.python.org/file11474/unnamed

___
Python tracker <[EMAIL PROTECTED]>

___--- Begin Message ---

New submission from Gerhard Häring <[EMAIL PROTECTED]>:

I'd really like this change to get into Python 2.6. It's pretty trivial
(just releases the GIL when compiling SQLite statements), but improves
concurrency for SQLite. This means less "database is locked" errors for
our users.

Could somebody please review this and give me an ok to check it in?

--
assignee: ghaering
files: sqlite_concurrency_prepare.diff
keywords: patch
messages: 73086
nosy: ghaering
severity: normal
status: open
title: sqlite3 module: Improved concurrency
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file11473/sqlite_concurrency_prepare.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3846] sqlite3 module: Improved concurrency

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

Your patch seems obvious, however:

- Is there the possibility that sqlite3_prepare() calls back into a
function in the _sqlite module or other python code? In this case the
GIL has to be re-acquired.

- What if another thread closes the current connection (or drop a table,
etc.) in-between? Is sqlite really thread-safe?

--
nosy: +amaury.forgeotdarc

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3103] sqlite defines a few global symbols.

[Gerhard Häring]

Gerhard Häring <[EMAIL PROTECTED]> added the comment:

Patch to Python 2.6 with Misc/NEWS entry if we want to close this now.

Added file: http://bugs.python.org/file11475/patch_sqlite3_global_symbols.dif

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3774] tkinter Menu.delete bug

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

Python 2.6b2 was released with this bug, and got fixed later.

--
resolution:  -> out of date
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3774] tkinter Menu.delete bug

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

I meant beta3, sorry.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3846] sqlite3 module: Improved concurrency

[Gerhard Häring]

Gerhard Häring <[EMAIL PROTECTED]> added the comment:

1. SQLite calling back

Good that you mention it. During sqlite3_prepare, SQLite can call the
authorizer_callback. Fortunately, it already acquires/releases the GIL
appropriately already.

2. Other thread closing connection, etc.

Connections/cursors cannot be shared among Python threads. Well, with
newer SQLite releases I think it is possible. But we have checks in
place that raise an error if you do it. These are the various calls to
pysqilte_check_thread in the code. If the table is dropped,
sqlite3_prepare will just raise an error about the statement not being
valid.

If, however, the table is dropped between sqlite3_prepare and
sqlite3_step, then the SQLITE_SCHEMA error code is returned. We then try
to recompile the statement (it might have just been an ALTER TABLE and
the statement is valid after compiling it again). If that still fails,
we promote the error to Python (cursor.c lines 605ff).

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3774] tkinter Menu.delete bug

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

Oops, sorry, I misread the bug report, reopening it (let me go eat
something now).

--
keywords:  -easy, needs review
resolution: out of date -> 
status: closed -> open

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3774] tkinter Menu.delete bug

[Guilherme Polo]

Changes by Guilherme Polo <[EMAIL PROTECTED]>:


--
keywords: +easy, needs review

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3774] tkinter Menu.delete bug

[Dan OD]

Dan OD <[EMAIL PROTECTED]> added the comment:

Thanks guys - I was running an old build. revision 65971 fixed this as Hirokazu 
mentioned.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1597850] Cross compiling patches for MINGW

[Luke Kenneth Casson Leighton]

Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> added the comment:

> In particular, I think that X-compiling is a common request

added another one to the list.

justification: pywebkitgtk cross-compiling for win32, using mingw32.
i'm not paying for microsoft license fees, i'm not paying for a
computer capable of running msvc, i'm not paying for the bandwidth
to download msvc and/or set it up.

much happier with mingw32, but mingw32 runs like an absolute dog
under wine - and often wine_server hangs.  (at least a 20x performance
hit for running msys and mingw32 under wine).

so... that leaves cross-compiling.

i need the development libraries from python 2.5 in order to create
a windows version of pywebkitgtk.

--
nosy: +lkcl

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3848] select.epoll calling register with the same fd fails

[Maries Ionel Cristian]

New submission from Maries Ionel Cristian <[EMAIL PROTECTED]>:

The docs on epoll object's register method say: "Registering a file
descriptor that’s already registered is not an error, and has the same
effect as registering the descriptor exactly once."

However when calling register twice with the same fd it will fail with a
bogus "IOError: [Errno 17] File exists" error.

--
assignee: georg.brandl
components: Documentation, Extension Modules
messages: 73096
nosy: georg.brandl, ionel.mc
severity: normal
status: open
title: select.epoll calling register with the same fd fails
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2747] Documentation of new gobject types fails

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

This turns out to be caused by the same problem that caused the
SQLAlchemy model failure: the module was imported twice by autodoc.

Should now be fixed in trunk and 0.4.x branch.

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

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3848] select.epoll calling register with the same fd fails

[Georg Brandl]

Changes by Georg Brandl <[EMAIL PROTECTED]>:


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

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3848] select.epoll calling register with the same fd fails

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

I'll look into it. kqueue should be checked for the issue, too.

Barry: I don't think it's a release blocker but it's your call.

--
nosy: +barry
priority:  -> critical
versions:  -Python 2.7, Python 3.1

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3774] tkinter Menu.delete bug

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

The patch attached is probably the most direct way to fix it, but, can
someone remind why we just don't call deletecommand (if there is a
command to delete) and let it try to remove the command from _tclCommand
then ? (note that this is not really the case for this bug report).
I'm attaching a patch that is a bit "different". It relies on the fact
that if the menu entry was created with add_command but no command was
specified, then there is no command to specify. And if a command was
specified then _tclCommands would be a list and deletecommand would work
properly.

Added file: http://bugs.python.org/file11476/issue3774.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3848] select.epoll calling register with the same fd fails

[Barry A. Warsaw]

Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:

Not a blocker.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3774] tkinter Menu.delete bug

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

Again, I meant the previously attached patch (the one by ocean-city) was
the most direct way.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3774] tkinter Menu.delete bug

[skomoroh]

skomoroh <[EMAIL PROTECTED]> added the comment:

Seems I found the bug.

I've attached the patch for current py3k-trunk.

Added file: http://bugs.python.org/file11477/menu_fix.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3774] tkinter Menu.delete bug

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

My patch already does what is proposed in your patch, except yours may
possibly not work. It is not guaranteed that "self.entrycget(i,
'command')" will return an empty string if the command associated to
that menu entry is an empty string. Tcl may return another object
containing the representation of this menu command so that if statement
will evalute as True while its representation is actually an empty string.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3848] select.epoll calling register with the same fd fails

[Maries Ionel Cristian]

Maries Ionel Cristian <[EMAIL PROTECTED]> added the comment:

Why don't just fix the docs ?
I think it's consistent with the epoll api the way it is now.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3848] select.epoll calling register with the same fd fails

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

It's not consistent with Python's select.poll API. But exarkun and I
think that an exception is fine here. The exception makes it easier to
spot issues.

The patch updates the docs and adds some tests for corner cases to
test_epoll.py

--
keywords: +patch
Added file: http://bugs.python.org/file11478/epoll.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3655] latexwriter: \footnotemark can only take numbers as arguments

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

This is now tracked in http://code.google.com/p/sphinx/issues/detail?id=13.

--
resolution:  -> postponed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3848] select.epoll calling register with the same fd fails

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

This should be removed from the docs patch:

-   Register a fd descriptor with the epoll object.
+  Register a fd descriptor with the epoll object.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3774] tkinter Menu.delete bug

[Hirokazu Yamamoto]

Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment:

self.deletecommand doesn't remove menu item, so we don't have to care
about index shifting like bellow. +1 for gpolo's patch.

>>> a = [0, 1, 2, 3]
>>> for i in xrange(len(a)):
... del a[i]
...
Traceback (most recent call last):
  File "", line 2, in 
IndexError: list assignment index out of range


I'm not sure (self._tclCommands is not None) check is not really needed.
I was looking for the place self._tclCommands is initialized, and found
_register() is that place, but what is 'needcleanup'? :-0
But probably, gpolo's patch is right.


P.S.
This is not related to this issue, I think
"""Delete menu items between INDEX1 and INDEX2 (not included)."""
should be changed to
"""Delete menu items between INDEX1 and INDEX2 (included)."""

Please look at http://www.tcl.tk/man/tcl8.5/TkCmd/menu.htm#M59

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3847] Begging for review

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

I don't think you meant to send this to the tracker.

--
nosy: +loewis

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3847] Begging for review

[Gerhard Häring]

Gerhard Häring <[EMAIL PROTECTED]> added the comment:

I accidentally created this issue

--
resolution:  -> invalid
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1597850] Cross compiling patches for MINGW

[Luke Kenneth Casson Leighton]

Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> added the comment:

the cross-compile fails on Parser/acceler.c
the reason is because the included file, pyconfig.h,
has "#define gid_t int" for use by the mingw32 compiler,
which is... bad!
removing gid_t from pyconfig.h bizarrely fixes the
compile without.. so far.. any issues

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1597850] Cross compiling patches for MINGW

[Luke Kenneth Casson Leighton]

Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> added the comment:

pyport.h line 773 - commenting out the test for LONG_BIT != 8 *
SIZEOF_LONG - we're cross-compiling amd64 host, target mingw32 - 32-bit.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1597850] Cross compiling patches for MINGW

[Luke Kenneth Casson Leighton]

Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> added the comment:

line 199 of thread_pthread.h  and line 221:
Python/thread_pthread.h:200: error: aggregate value used where an
integer was expected

hmmm... maybe this is due to me using mingw32 based on gcc 4.4.4.

well, a quick #if 0 seems to fix it :)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1597850] Cross compiling patches for MINGW

[Luke Kenneth Casson Leighton]

Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> added the comment:

posixmodule.c - line 2328:
add this:

#if ( defined(__MINGW32__) || defined(__WATCOMC__) ||
defined(PYCC_VACPP) ) && !defined(__QNX__)
res = mkdir(path);
#else
res = mkdir(path, mode);
#endif

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1597850] Cross compiling patches for MINGW

[Luke Kenneth Casson Leighton]

Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> added the comment:

posixmodule: line 3530:

#ifdef __MINGW32__
master_fd = open(DEV_PTY_FILE, O_RDWR); /* open master */
#else
master_fd = open(DEV_PTY_FILE, O_RDWR | O_NOCTTY); /* open master */
#endif

not sure i should be compiling posixmodule under mingw32 :)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1597850] Cross compiling patches for MINGW

[Luke Kenneth Casson Leighton]

Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> added the comment:

line 6193:

#if !defined(__MINGW32__) && !defined(MS_WINDOWS) && defined(HAVE_FCNTL_H)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3103] sqlite defines a few global symbols.

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

The patch is fine, please try to apply it before rc1. If rc1 gets
missed, it should be defered to 2.7.

--
resolution:  -> accepted

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3842] can't run close through itertools.chain on inner generator

[Bruce Frederiksen]

Bruce Frederiksen <[EMAIL PROTECTED]> added the comment:

What you propose is not portable code.  It won't work on jython or 
ironpython or pypy because they don't have reference counting garbage 
collectors that immediately reclaim objects.

Also I'm not asking that all c-based iterators grow a 'close' method 
(though this would be nice! :-) ).

For all other c-based iterators, you can do:

with closing(gen()) as argument:
for x in map(fn, argument): ...

which is portable.

So I am only asking that 'close' be added to itertools.chain because 
there is no portable solution there.

-bruce

Amaury Forgeot d'Arc wrote:
> Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
>
> You somehow must tell the iterator that you are done with it.
> This is best done by a "del c" in your first snippet, since c is the
> last reference to the iterator. 
> To do this in a function (or a context manager), the trick is to wrap
> the map() iterator inside a generator function.
>
> def wrapiterator(it):
> for x in it:
> yield x
>
> Then your sample becomes:
>   
 with closing(wrapiterator(chain.from_iterable(
 
> ...  map(gen, (1,2,3) as c:
> ...next(c)
>
>
> Which of course can be rewritten as:
>
> def closingiterator(it):
> def wrapper():
> for x in it:
> yield x
> return closing(wrapper())
>
>   
 with closingiterator(chain.from_iterable(map(gen, (1,2,3) as c:
 
> ...next(c)
>
>
> This works because the only reference to the map() iterator is held by
> the wrapper generator function. Calling its close() method will
> terminate the function, delete its locals, ultimately call the
> deallocator of the gen() iterator, which will fire the "finally" block.
>
> Your proposal implies that all c-based iterators need to grow a "close"
> method. This is not practical, and is best simulated with this wrapper
> generator: close()ing the wrapper will (recursively) destroy the iterators.
> If this also works for you, I suggest to close this issue.
>

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3774] tkinter Menu.delete bug

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

This "needcleanup" parameter indicates that the function added to
_tclCommands needs to (and will) be removed later. Nevertheless, I
believe the proper initialization of _tclCommands should be done elsewhere.


And about that docstring.. yes, the change is needed. (I could swear I
saw it fixed some time ago, but no.. it didn't happen)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3841] IDLE: quirky behavior when displaying strings longer than 4093 characters

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

Where is the test case ?

--
nosy: +gpolo

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3846] sqlite3 module: Improved concurrency

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

Asking in the same direction: what is the consequence of this patch when
check_same_thread is False? Couldn't that result in very problematic
overlappings, e.g. when two threads try to execute statements on the
same cursor?

--
nosy: +loewis

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3849] FUD in documentation for urllib.urlopen()

[raz]

New submission from raz <[EMAIL PROTECTED]>:

The documentation for urllib.urlopen() states:

"One caveat: the read() method, if the size argument is omitted or
negative, may not read until the end of the data stream; there is no
good way to determine that the entire stream from a socket has been read
in the general case."

To an innocent reader this effectively translates to:
"The read() method may silently truncate your data but we won't tell you
any details about it."

The paragraph should be clarified as follows:

- Under what circumstances can truncation happen (which protocols are
affected, under which conditions?)
- What are safe use-cases where truncation can not happen (e.g. the
common case of a simple HTTP-GET)

--
assignee: georg.brandl
components: Documentation
messages: 73122
nosy: georg.brandl, raz
severity: normal
status: open
title: FUD in documentation for urllib.urlopen()
type: behavior
versions: Python 2.4, Python 2.5

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3774] tkinter Menu.delete bug

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

New patch, this one fixes the docstring previously mentioned and may set
_tclCommands to an empty list at BaseWidget.__init__

Added file: http://bugs.python.org/file11479/issue3774_2.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3846] sqlite3 module: Improved concurrency

[Gerhard Häring]

Gerhard Häring <[EMAIL PROTECTED]> added the comment:

Interesting. I was smart enough to not document check_same_thread in the
sqlite3 incarnation of the module.

This has nothing to do with releasing/aquiring the GIL around
sqlite3_prepare, though. Adding the macros was just an oversight.
They're there for all other nontrivial SQLite API calls (sqlite3_step,
sqlite3_reset, sqlite3_open, sqlite3_finalize and also already for the
"BEGIN"/"COMMIT" and "ROLLBACK" versions of sqlite3_prepare in connection.c.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3846] sqlite3 module: Improved concurrency

[Gerhard Häring]

Gerhard Häring <[EMAIL PROTECTED]> added the comment:

Just to be explicit: check_same_thread is unsupported and while it's
undocumented in sqlite3, the old pysqlite docs say that when you use it,
you have to make sure the connections/cursors are protected otherwise
(via your own mutexes).

[In the current pysqlite docs it's not documented at all at the moment,
because I derived these from the Python sqlite3 ones]

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3657] pickle can pickle the wrong function

[Tim Peters]

Tim Peters <[EMAIL PROTECTED]> added the comment:

No thought went into picking random.random in the test -- it was just a
random ;-) choice.  Amaury's analysis of the source of non-determinism
is on target, and the easiest fix is to pick a coded-in-Python function
to pickle instead.  I suggest, e.g., changing the sporadically failing
doctest to:

>>> import pickletools
>>> dis(pickle.dumps(pickletools.dis, 0))
0: cGLOBAL 'pickletools dis'
   17: pPUT0
   20: .STOP
highest protocol among opcodes = 0

--
nosy: +tim_one

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3846] sqlite3 module: Improved concurrency

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

> This has nothing to do with releasing/aquiring the GIL around
> sqlite3_prepare, though. 

You mean, it doesn't make things worse, but I believe they do
(even if so only slightly). If you have two threads simultaneously
attempting an execute on a cursor, one will run into the prepare.

That thread will (now) release the GIL, allowing the second thread
to run into the prepare. That thread will replace the statement object
in the cursor, so when the first thread returns, the statement has
changed underneath, and it will associate any return code with the
incorrect statement object.

In this form, this can't currently happen. Without detailed review,
I can readily believe that there are many other cases where a
False check_same_thread can give surprising results.

> They're there for all other nontrivial SQLite API calls (sqlite3_step,
> sqlite3_reset, sqlite3_open, sqlite3_finalize and also already for the
> "BEGIN"/"COMMIT" and "ROLLBACK" versions of sqlite3_prepare in connection.c.

On the grounds that the code is already full of these GIL release calls,
I'll approve this additional one.

I encourage you to review the entire issue, though, and document
somewhere what promises are made under what conditions. Then a later
review can validate that the promises are really kept.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3846] sqlite3 module: Improved concurrency

[Martin v. Löwis]

Changes by Martin v. Löwis <[EMAIL PROTECTED]>:


--
resolution:  -> accepted

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3617] Add MS EULA to the list of third-party licenses in the Windows installer

[Van Lindberg]

Van Lindberg <[EMAIL PROTECTED]> added the comment:

Sorry for the long comment. There are two parts to this comment. First,
my recommendation, and second, the somewhat tedious analysis of the
Microsoft EULAs. The second part is the verbiage to justify the first.

Recommendation
==

To comply with Microsoft's EULA, the PSF should include text like the
following in the Windows binary installer license text:



"This program is linked with and uses Microsoft Distributable Code,
copyrighted by Microsoft Corporation. The Microsoft Distributable Code
includes the following files:

[...]

If you further distribute programs that include the Microsoft
Distributable Code, you must comply with the restrictions on
distribution specified by Microsoft. In particular, you must require
distributors and external end users to agree to terms that protect the
Microsoft Distributable Code at least as much as Microsoft's own
requirements for the Distributable Code. See Microsoft's documentation
(included in its developer tools and on its website at microsoft.com)
for specific details.

Redistribution of the Windows binary build of the Python interpreter
complies with this agreement, provided that you do not:

- alter any copyright, trademark or patent notice in Microsoft's
Distributable Code;

- use Microsoft’s trademarks in your programs’ names or in a way that
suggests your programs come from or are endorsed by Microsoft;

- distribute Microsoft's Distributable Code to run on a platform other
than Microsoft operating systems, run-time technologies or application
platforms;

- include Microsoft Distributable Code in malicious, deceptive or
unlawful programs; or

- modify or distribute the source code of any Microsoft Distributable
Code so that any part of it becomes subject to an Excluded License.  An
Excluded License is one that requires, as a condition of use,
modification or distribution, that the code be disclosed or distributed
in source code form; or others have the right to modify it.

These restrictions apply only to the Microsoft Distributable Code as
defined above, not to Python itself or any programs running on the
Python interpreter. The redistribution of the Python interpreter and
libraries is governed by the Python Software License included with this
file, or by other licenses as marked.



Commentary on the distribution requirements
===

VS 2008 (labels added for clarity)
--


"ii.Distribution Requirements.  For any Distributable Code you
distribute, you must

(A) add significant primary functionality to it in your programs;"

This term is satisfied by the addition of the Python interpreter.


(B) "for any Distributable Code having a filename extension of .lib,
distribute only the results of running such Distributable Code through a
linker with your program;"

This prohibits distributing libraries in .lib form. Based on what I see
in the MSI, we do not do this. We do include _msi.lib, but that is not
Microsoft's _msi.lib, but the ready-for linking version of MvL's msilib.


(C) "distribute Distributable Code included in a setup program only as
part of that setup program without modification;"

Python does not include any Distributable Code included in a setup program.


(D) "require distributors and external end users to agree to terms that
protect it at least as much as this agreement;"

This term specifies that any Distributable Code that we distribute must
itself have some sort of agreement that protects Microsoft's rights in
"it" (the code) "at least as much as this agreement."

The important term here is "it." The antecedent here is "Distributable
Code you distribute," (Microsoft's code, in this case the msvcrt.dll),
not "your programs" (Python). 


(E) "display your valid copyright notice on your programs; and"

Python complies with this requirement, as we display our own license
agreement and include sys.copyright.


(F) "indemnify, defend, and hold harmless Microsoft from any claims,
including attorneys’ fees, related to the distribution or use of your
programs."

Under this provision, we agree not to sue Microsoft for distributing Python.


"iii. Distribution Restrictions.  You may not

(G) alter any copyright, trademark or patent notice in the Distributable
Code;"

Python complies with this requirement, as the Microsoft Distributable
Code is distributed unaltered.


(H) "use Microsoft’s trademarks in your programs’ names or in a way that
suggests your programs come from or are endorsed by Microsoft;"

Python complies with this requirement, as we do use Microsoft's
trademarks in the program name and we don't suggest that Python comes
from or is endorsed by Microsoft.


(I) "distribute Distributable Code to run on a platform other than
Microsoft operating systems, run-time technologies or application
platforms;"

While Python could technically run on non-Microsoft platforms (e.g.
Wine), the Windows binar

[issue3841] IDLE: quirky behavior when displaying strings longer than 4093 characters

[Stephen McInerney]

Stephen McInerney <[EMAIL PROTECTED]> added the comment:

(I previously attached testcase with the web form, but it doesn't seem 
to work. So I'm pasting it here:)

# Generate a length-4094 string.
# IDLE will not display this unless your cursor is inside the string.
# If you delete characters so length <= 4093, IDLE displays it ok.
# Python versions: believed to be all
# OS: Windows Vista (maybe others)

#verylongstring = "1 3 5 7 9 " * 409 + "1 3 "
verylongstring = "1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 
9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 
1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 
3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 
9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 
1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 
3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 
9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 
1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 
3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 
9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 
1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 
3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 
9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 
1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 
3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 
9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 
1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 
3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 
9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 
1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 
3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 
9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 
1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 
3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 
9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 
1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 
3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 
9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 
1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 
3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 
9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 
1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 
3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 "
print len(verylongstring)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3841] IDLE: quirky behavior when displaying strings longer than 4093 characters

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

I don't think I can reproduce this under Linux with the idlelib in
python-trunk.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3850] find_recursion_limit.py is broken

[Antoine Pitrou]

New submission from Antoine Pitrou <[EMAIL PROTECTED]>:

find_recursion_limit.py in trunk is broken: it fails with an
AttributeError while a RuntimeError is expected. This has appeared due
to the recent changes in recursion limit handling, but the problem is
deeper. As I explained on the ML, functions like PyDict_GetItem()
discard any exception that occur inside them, and return NULL instead.
The caller can then interpret the NULL as an "attribute missing" and
raise AttributeError.

The obvious quick fix is to replace "except RuntimeError" with "except
(RuntimeError, AttributeError)" in find_recursion_limit.py.

--
components: Demos and Tools
keywords: easy
messages: 73131
nosy: pitrou
priority: high
severity: normal
status: open
title: find_recursion_limit.py is broken
type: behavior
versions: Python 2.6

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3640] test_cpickle crash on AMD64 Windows build

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

I've opened #3850 for the find_recursion_limit problem.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3841] IDLE: quirky behavior when displaying strings longer than 4093 characters

[Stephen McInerney]

Stephen McInerney <[EMAIL PROTECTED]> added the comment:

This may well be Windows-only or maybe even Windows Vista-only.

I don't have ready access to other OS installs so could someone who 
does please try to repro?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3850] find_recursion_limit.py is broken

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Here is a patch.

--
keywords: +needs review, patch
Added file: http://bugs.python.org/file11480/find_recursion_limit.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3851] IDLE: Pressing "Home" on Windows places cursor before ">>>" instead of after. Solution offered.

[Roger Serwy]

Changes by Roger Serwy <[EMAIL PROTECTED]>:


--
nosy: serwy
severity: normal
status: open
title: IDLE: Pressing "Home" on Windows places cursor before ">>>" instead of 
after. Solution offered.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3850] find_recursion_limit.py is broken

[Alexandre Vassalotti]

Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment:

Could you use PyDict_GetItemWithError() to avoid this?

--
nosy: +alexandre.vassalotti

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3850] find_recursion_limit.py is broken

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

It's not my code, it's the interpreter's code which uses
PyDict_GetItem() all over the place, and the aim of
find_recursion_limit.py is precisely to test the function call paths
inside the interpreter.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3657] pickle can pickle the wrong function

[Alexandre Vassalotti]

Changes by Alexandre Vassalotti <[EMAIL PROTECTED]>:


--
nosy: +alexandre.vassalotti

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3851] IDLE: Pressing "Home" on Windows places cursor before ">>>" instead of after. Solution offered.

[Roger Serwy]

New submission from Roger Serwy <[EMAIL PROTECTED]>:

Pressing "Home" on Windows XP in the PyShell window places the cursor
before ">>>" instead of after it. On Linux, this behaves correctly.

The problem is in PyShell.py in the home_callback(). At line 1064:

if event.state != 0 and event.keysym == "Home":
return

"event.state" returns 8 on Windows when Home is pressed, thus the
callback never executes. Here are two solutions:

event.mc_state != 0

or

(event.state & 1) != 0

This fixes the problem on Windows, and still works under Linux.

--
components: +IDLE
type:  -> behavior
versions: +Python 2.5

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3657] pickle can pickle the wrong function

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

But it still means pickling a function/method defined in a builtin
extension module can give wrong results, doesn't it deserve being fixed?

--
nosy: +pitrou

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3849] FUD in documentation for urllib.urlopen()

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Would you be interested in working on a patch?

--
nosy: +benjamin.peterson

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3617] Add MS EULA to the list of third-party licenses in the Windows installer

[Marc-Andre Lemburg]

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:

Thank you, Van, for this comprehensive analysis.

By including your text we'll also bypass the issues with finding the
EULA file in the Visual Studio installation.

The text should be easy to add as extra file and we can then reference
this file in the MSI installer builder (much like we do for all other
3rd party licenses. I can't help with that in the next few days, though,
since I'm on vacation the next week.

One nit I found with the text, but that may not be legally relevant: The
MS website does not appear to list the EULA texts anywhere.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3842] can't run close through itertools.chain on inner generator

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

Sorry, am going to reject this.   The use cases are somewhat uncommon
and I don't want to clutter-up tools that need to remain as simple as
possible.  The pure python code for chain() is so simple that it's not
hard to roll your own version as needed.

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

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3318] Documentation: timeit: "lower bound" should read "upper bound"

[unutbu]

unutbu <[EMAIL PROTECTED]> added the comment:

Let B = the set of all possible times on a particular machine (the machine on 
which the timeit script is run).
Let x = the minimum of B. 
Then "the lowest value is an upper bound for x".
This is correct, accurate, not an oxymoron.
The above does not refer to an ideal machine, nor does it refer to the fastest 
machine.

Let's try to agree on a principle: Every statement made in documentation should 
be correct and have meaningful substance. 

If we can agree on this principle, then I think we will have to agree that the 
paragraph:

"""
Note: It's tempting to calculate mean and standard deviation from the result 
vector and report these. However, this is not very useful. In a typical case, 
the lowest value gives a lower bound for how fast your machine can run the 
given code snippet; higher values in the result vector are typically not caused 
by variability in Python's speed, but by other processes interfering with your 
timing accuracy. So the min() of the result is probably the only number you 
should be interested in. After that, you should look at the entire vector and 
apply common sense rather than statistics.
"""

can not stay the way it is.

Here is why:

The correctness of the sentence, "In a typical case, the lowest value gives a 
lower bound for how fast your machine can run the given code snippet" relies on 
the presence of the word "typical". But what does typical mean? Here we come to 
the second half of the principle: the sentence must have meaning and substance.

By relying on the word typical, we reduce the sentence to meaninglessness, 
because there is no way to endow the word "typical" with meaning without also 
making the sentence incorrect. For example, if we tried to make the sentence 

"In a typical case, the lowest value gives a lower bound for how fast your 
machine can run the given code snippet"

mean

"If you run the snippet 100 times, the lowest value would be less than the time 
in 50 cases"

then you run the risk of making a claim that may not be true.

The critical reader will be forced to simply throw away the entire paragraph as 
nonsense.

The uncritical reader may believe the output of timeit.repeat is less than or 
equal to x, which is simply not true. The output of timeit.repeat might not 
even be near x (whatever near means!) if for example, the script were being run 
on a server while lots of other processes were being run, or if there was a 
process with nice priority -19 running simultaneously.

What do you think we should do?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3657] pickle can pickle the wrong function

[Tim Peters]

Tim Peters <[EMAIL PROTECTED]> added the comment:

Amaury, yes, it would be nice if pickle were more reliable here.  But
that should be the topic of a different tracker issue.  Despite the
Title, this issue is really about sporadic pickletools.py failures, and
the pickletools tests are trying to test pickletools, not pickle.py (or
cPickle).  Changing the test as suggested makes it reliably test what
it's trying to test (namely that pickletools.dis() produces sensible
output for pickle's GLOBAL opcode).  Whether pickle/cPickle should do a
better job of building GLOBAL opcodes in the first place is a distinct
issue.

In any case, since pickle/cPickle have worked this way forever, and the
only known bad consequence to date is accidental sporadic test failures
in pickletools.py, the underlying pickle/cPickle issue shouldn't be a
release blocker regardless.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3852] kqueue.control requires 2 params while docs say max_events (the second) defaults to 0

[Maries Ionel Cristian]

New submission from Maries Ionel Cristian <[EMAIL PROTECTED]>:

http://docs.python.org/dev/library/select.html#id1

Docs say: "select.control(changelist, max_events=0[, timeout=None])"
However, control requires 2 params ("TypeError: control() takes at least
2 arguments (1 given)").

Also, it should be "kqueue" not "select" (There are 2 more like this
"epoll.fromfd(fd)" in the kqueue section, "select.kqueue(ident,
filter=KQ_FILTER_READ, flags=KQ_ADD, fflags=0, data=0, udata=0)" instead
of "select.kevent( ... ")

--
assignee: georg.brandl
components: Documentation, Extension Modules
messages: 73144
nosy: georg.brandl, ionel.mc
severity: normal
status: open
title: kqueue.control requires 2 params while docs say max_events (the second) 
defaults to 0
type: behavior
versions: Python 2.6, Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3617] Add MS EULA to the list of third-party licenses in the Windows installer

[Van Lindberg]

Van Lindberg <[EMAIL PROTECTED]> added the comment:

The important part is that we point out the Microsoft redistributables
are subject to Microsoft's restrictions; we don't need to point to a
specific EULA URL. People installing Python will agree to the license
terms as they apply to the different pieces of the binary, and thus
satisfy the PSF's obligation.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3846] sqlite3 module: Improved concurrency

[Gerhard Häring]

Gerhard Häring <[EMAIL PROTECTED]> added the comment:

Thanks, Martin.

Commited as r66414.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3103] sqlite defines a few global symbols.

[Gerhard Häring]

Gerhard Häring <[EMAIL PROTECTED]> added the comment:

Committed in r66412.

--
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3853] Windows SQLite DLL should be built with multithreading enabled

[Gerhard Häring]

New submission from Gerhard Häring <[EMAIL PROTECTED]>:

According to http://www.sqlite.org/faq.html#q6 SQLite should be built
with SQLITE_THREADSAFE defined when the library is used in a
multithreaded context.

This doesn't mean that the connection objects can then be shared between
threads. This they cannot. But that if the SQLite API is used from more
than one thread, then the library must be built with the
SQLITE_THREADSAFE option.

--
assignee: loewis
components: Build, Windows
keywords: easy
messages: 73148
nosy: ghaering, loewis
priority: high
severity: normal
status: open
title: Windows SQLite DLL should be built with multithreading enabled
type: feature request
versions: Python 2.6, Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3854] Document sqlite3 vs. threads

[Gerhard Häring]

New submission from Gerhard Häring <[EMAIL PROTECTED]>:

In Issue3846, Martin proposed [...] I encourage you to review the
entire issue, though, and document
somewhere what promises are made under what conditions. Then a later
review can validate that the promises are really kept."""

Currently it's documented nowhere how the C implementation of the
sqlite3 module handles multithreading issues.

--
assignee: ghaering
components: Documentation
messages: 73149
nosy: ghaering
priority: normal
severity: normal
status: open
title: Document sqlite3 vs. threads
type: feature request
versions: Python 2.7, Python 3.1

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3846] sqlite3 module: Improved concurrency

[Gerhard Häring]

Gerhard Häring <[EMAIL PROTECTED]> added the comment:

Issue3854 was created for documenting sqlite3 vs. threads.

--
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3659] sqlite: enumeration value 'TYPE_STRING' not handled in switch

[Gerhard Häring]

Gerhard Häring <[EMAIL PROTECTED]> added the comment:

I'll look into this.

--
assignee:  -> ghaering
nosy: +ghaering

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3852] kqueue.control requires 2 params while docs say max_events (the second) defaults to 0

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


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

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3657] pickle can pickle the wrong function

[Barry A. Warsaw]

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:


--
priority: release blocker -> high

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1034] [patch] Add 2to3 support for displaying warnings as Python comments

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

On the patch:
1. I think both a log message and the comment should be written. The
point needs to be reinforced to users.
2. I'd like to see some tests.
3. Maybe an option to turn the auto comments off?


This is interesting. I'd like to have someone else weigh in before it is
applied though.

--
nosy: +benjamin.peterson

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3000] 2to3 doesn't handle print(whatever); print nor string.* functions

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

The print problem was fixed in r66418. The string problem is a duplicate
of #2899.

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

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3321] _multiprocessing.Connection() doesn't check handle

[Daniel Diniz]

Changes by Daniel Diniz <[EMAIL PROTECTED]>:


--
nosy: +ajaksu2

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3358] 2to3 Iterative Wildcard Matching

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Nick, it would be nice if your patch had a test.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1681984] unittest documentation is incomplete

[Daniel Diniz]

Changes by Daniel Diniz <[EMAIL PROTECTED]>:


--
nosy: +ajaksu2

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3288] float.as_integer_ratio method is not documented

[A.M. Kuchling]

A.M. Kuchling <[EMAIL PROTECTED]> added the comment:

While writing docs for as_integer_ratio(), I noticed a few typos in the
docstrings of the new float methods.  Patch attached.

--
nosy: +akuchling
Added file: http://bugs.python.org/file11481/float-docstring.txt

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3632] use string_print() in gdb

[Daniel Diniz]

Daniel Diniz <[EMAIL PROTECTED]> added the comment:

I would love to have this patch, along with those of #3631 and #3610,
included in Misc as diffs. This would make it easier to get the improved
functionality in a new development box, besides allowing distributions
to apply them at will.

--
nosy: +ajaksu2

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3288] float.as_integer_ratio method is not documented

[A.M. Kuchling]

A.M. Kuchling <[EMAIL PROTECTED]> added the comment:

The attached patch documents the as_integer_ratio method; I'll commit it 
once Barry allows commits.

Added file: http://bugs.python.org/file11482/stdtypes.txt

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3311] block operation on closed socket/pipe for multiprocessing

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
keywords: +needs review
priority:  -> critical

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3321] _multiprocessing.Connection() doesn't check handle

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
keywords: +needs review
priority: high -> critical

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3321] _multiprocessing.Connection() doesn't check handle

[Jesse Noller]

Jesse Noller <[EMAIL PROTECTED]> added the comment:

Without someone offering some windows help, I won't be able to do a patch. 
My windows fu is lacking.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue687648] classic division in demos/ directory

[A.M. Kuchling]

A.M. Kuchling <[EMAIL PROTECTED]> added the comment:

Changes to curses/ committed in rev. 66424.

Changes to threading/ committed in rev. 66425.

Changes to Demo/classes/Dates.py committed in rev. 66426.

Changes to md5driver/ committed in rev. 66427.

Rest of the changes committed in rev. 66428.

Robert, thank you very much for your patch!

--
assignee:  -> akuchling
nosy: +akuchling
resolution:  -> accepted
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3850] find_recursion_limit.py is broken

[A.M. Kuchling]

A.M. Kuchling <[EMAIL PROTECTED]> added the comment:

The patch seems fine to me.

The docstring at the top of the file says:

It ends when Python causes a segmentation fault because the limit is
too high.  On platforms like Mac and Windows, it should exit with a
MemoryError.

On my Macbook, it segfaults; perhaps that docstring applied only 
to MacOS 9?

--
nosy: +akuchling

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3288] float.as_integer_ratio method is not documented

[A.M. Kuchling]

A.M. Kuchling <[EMAIL PROTECTED]> added the comment:

Patch committed in rev. 66435.

Do we want to mention it in the tutorial?  If not,
this issue could now be closed.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3825] Major reworking of Python 2.5.2 re module

[Terry J. Reedy]

Terry J. Reedy <[EMAIL PROTECTED]> added the comment:

Atomic groups and possessive quantifiers appear to be relatively new:
http://en.wikipedia.org/wiki/Regular_expressions
for instance, has no mention of either that I found.

http://www.regular-expressions.info/atomic.html
http://www.regular-expressions.info/possessive.html
seemed pretty clear to me.  If they accurately describe what you are
adding, they might be a starting point for the needed new manual
sections.  They should include a warning about carefully ordering
alternatives lest one prune too much.

--
nosy: +tjreedy

___
Python tracker <[EMAIL PROTECTED]>

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