[issue2539] Windows Registry issue with 2.5.2 AMD64 msi
New submission from Jason <[EMAIL PROTECTED]>: I have tried multiple times and even checking manually, but the Python 2.5.2 AMD64 msi installer does not register Python correctly, or it doesn't enter it into the registry correctly. I'm not sure. I install it after uninstalling 2.5.1 and and when I try to install wxPython2.8 and pygtk-2.10.6 both give me an error that they cannot find Python or its path in the registry. I reinstall 2.5.1 and it all works perfectly. I'm using all default selections and just clicking "Next,Next,Next, etc." -- components: Installation messages: 64887 nosy: iggyboo severity: normal status: open title: Windows Registry issue with 2.5.2 AMD64 msi versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2539> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2539] Windows Registry issue with 2.5.2 AMD64 msi
Jason <[EMAIL PROTECTED]> added the comment: I did a per-machine installation (Install for all users). I don't have the registry information at the moment, but I'll do some more uninstalling and reinstalling and get that information to you. Martin v. Löwis wrote: > Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > > Do you perform a per-user or per-machine installation? > > When you look at the Python registry keys, which ones get written? > > -- > nosy: +loewis > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue2539> > __ > __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2539> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34238] When BROWSER is set on Mac webbrowser.register_standard_browsers doesn't work
Jason added the comment: Yes, it does. I haven't tried that code, but it looks similar to a fix I implemented locally. Jason O'Gray On Sun, Dec 2, 2018 at 2:41 PM Karthikeyan Singaravelan < [email protected]> wrote: > > Karthikeyan Singaravelan added the comment: > > > However, I think there might be a bug with the implementation that > doesn't correctly respect the BROWSER preference. Notice how the > webbrowser._tryorder has two 'lynx' items and both of them > are last. If you look at the comment in the code, it says that it should > be prepended to _tryorder because it's the preferred browser > > @ograycode Is this similar to issue35308 ? > > -- > nosy: +xtreak > > ___ > Python tracker > <https://bugs.python.org/issue34238> > ___ > -- ___ Python tracker <https://bugs.python.org/issue34238> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32051] Possible issue in multiprocessing doc
New submission from jason :
in multiprocessing doc https://docs.python.org/3.6/library/multiprocessing.html
under 17.2.2.7.2. Using a remote manager,
>>> from multiprocessing.managers import BaseManager
>>> import queue
>>> queue = queue.Queue()
>>> class QueueManager(BaseManager): pass
>>> QueueManager.register('get_queue', callable=lambda:queue)
>>> m = QueueManager(address=('', 5), authkey=b'abracadabra')
>>> s = m.get_server()
>>> s.serve_forever()
queue is used as both module name and variable name, should this be avoided?
--
assignee: docs@python
components: Documentation
messages: 306389
nosy: 1a1a11a, docs@python
priority: normal
severity: normal
status: open
title: Possible issue in multiprocessing doc
type: enhancement
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue32051>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32051] Possible issue in multiprocessing doc
jason added the comment: Thank you for answering! Yes, I would be very happy to do that, this is going to be my first contribution! :) -- ___ Python tracker <https://bugs.python.org/issue32051> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32051] Possible issue in multiprocessing doc
Change by Jason : -- keywords: +patch pull_requests: +4401 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue32051> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32051] Possible issue in multiprocessing doc
Jason added the comment:
Hi Berker,
I didn't update "following examples with ``('', 5)`` too." because this
is different than the previous one, this is client connecting to server, so
hostname cannot be empty string.
--
___
Python tracker
<https://bugs.python.org/issue32051>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33836] [Good first-time issue] Recommend keyword-only param for memoization in FAQ
Jason added the comment: Hey Zach, Can I get this one? I haven't contributed anything yet. Cheers, Jason -- nosy: +codecamelot ___ Python tracker <https://bugs.python.org/issue33836> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34238] When BROWSER is set on Mac webbrowser.register_standard_browsers doesn't work
New submission from Jason :
Description: When BROWSER is set, webbrowser.get fails because
register_standard_browsers throws an error.
Work around: You can still use `webbroswer._browsers[key][1].open(url)` to open
a browser.
Operating system: macOS High Sierra v10.13.6
Reproduction 1:
```
➜ BROWSER=lynx python3
Python 3.7.0 (default, Jul 23 2018, 20:22:55)
[Clang 9.1.0 (clang-902.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import webbrowser
>>> webbrowser.get()
Traceback (most recent call last):
File "", line 1, in
File
"/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/webbrowser.py",
line 42, in get
register_standard_browsers()
File
"/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/webbrowser.py",
line 567, in register_standard_browsers
cmd = _synthesize(cmdline, -1)
File
"/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/webbrowser.py",
line 116, in _synthesize
register(browser, None, controller, update_tryorder)
TypeError: register() takes from 2 to 3 positional arguments but 4 were given
```
Reproduction 2:
```
➜ BROWSER=lynx python3
Python 3.7.0 (default, Jul 23 2018, 20:22:55)
[Clang 9.1.0 (clang-902.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import webbrowser
>>> webbrowser.register_standard_browsers()
Traceback (most recent call last):
File "", line 1, in
File
"/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/webbrowser.py",
line 567, in register_standard_browsers
cmd = _synthesize(cmdline, -1)
File
"/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/webbrowser.py",
line 116, in _synthesize
register(browser, None, controller, update_tryorder)
TypeError: register() takes from 2 to 3 positional arguments but 4 were given
>>> webbrowser.lynx
Traceback (most recent call last):
File "", line 1, in
AttributeError: module 'webbrowser' has no attribute 'lynx'
>>> webbrowser._browsers
{'macosx': [None, ],
'chrome': [None, ],
'firefox': [None, ],
'safari': [None, ], 'lynx':
[None, ]}
>>> webbrowser._browsers['lynx'].open('http://google.com')
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'list' object has no attribute 'open'
>>> webbrowser._browsers['lynx'][1].open('http://google.com') # This works
True
```
--
components: macOS
messages: 322439
nosy: ned.deily, ograycode, ronaldoussoren
priority: normal
severity: normal
status: open
title: When BROWSER is set on Mac webbrowser.register_standard_browsers doesn't
work
type: crash
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue34238>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34238] When BROWSER is set on Mac webbrowser.register_standard_browsers doesn't work
Change by Jason : -- type: crash -> ___ Python tracker <https://bugs.python.org/issue34238> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34238] When BROWSER is set on Mac webbrowser.register_standard_browsers doesn't work
Jason added the comment:
Serhiy, I believe you are correct. I updated my local python and it passed.
However, I think there might be a bug with the implementation that doesn't
correctly respect the BROWSER preference. If I do:
```
➜ BROWSER=lynx python3
Python 3.7.0 (default, Jul 23 2018, 20:22:55)
[Clang 9.1.0 (clang-902.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import webbrowser
>>> webbrowser.register_standard_browsers()
>>> webbrowser._tryorder
['MacOSX', 'chrome', 'firefox', 'safari', 'lynx', 'lynx']
>>> webbrowser._browsers
{'macosx': [None, ],
'chrome': [None, ],
'firefox': [None, ],
'safari': [None, ],
'lynx': [None, ]}
```
Notice how the webbrowser._tryorder has two 'lynx' items and both of them
are last. If you look at the comment in the code, it says that it should be
prepended to _tryorder because it's the preferred browser. See
https://github.com/python/cpython/blob/56b29b6d6fa3eb32bb1533ee3f21b1e7135648a0/Lib/webbrowser.py#L563
If I change `cmd = _synthesize(cmdline, preferred=False)`, line 566, to
preferred=True then the output is like this:
```
>>> webbrowser._tryorder
['lynx', 'MacOSX', 'chrome', 'firefox', 'safari', 'lynx']
```
Which I believe is closer to being correct based upon the comments in the
code.
Am I wrong about this, and should I open up a new bug report for it?
Thanks.
On Thu, Jul 26, 2018 at 1:49 PM Serhiy Storchaka
wrote:
>
> Serhiy Storchaka added the comment:
>
> I think it is fixed in issue31014.
>
> --
> nosy: +serhiy.storchaka
>
> ___
> Python tracker
> <https://bugs.python.org/issue34238>
> ___
>
--
___
Python tracker
<https://bugs.python.org/issue34238>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46090] C extensions can't swap out live frames anymore
Change by Jason Madden : -- nosy: +jmadden ___ Python tracker <https://bugs.python.org/issue46090> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46179] Delete selected item generate "<>" event or not in different version of tkinter or Python
New submission from Jason Yang :
In python(3.8.10)/tkinter(8.6.9), it won't generate "<>" event
if we delete selected item of ttk.Treeview, but it will for
python(3.9.9/3.10.1)/tkinter(8.6.12).
Check it just by clicking 'Delete Item 1' button in following demo code
```python
import sys
from random import randint
from datetime import datetime
import tkinter as tk
from tkinter import ttk
def button_callback():
button.configure(state='disabled')
treeview.delete(1)
def treeview_callback(event):
print(datetime.now().strftime("%H:%M:%S"), "Treeview selection changed !")
print(f"Python version : {sys.version.split(' ')[0]}")
print(f"tkinter version: {tk.Tcl().eval('info patchlevel')}")
columns = ('President', 'Birthday')
data = [
('Ronald Reagan', 'February 6'),
('Abraham Lincoln', 'February 12'),
('George Washington', 'February 22'),
('Andrew Jackson', 'March 15'),
('Thomas Jefferson', 'April 13'),
]
root = tk.Tk()
treeview = ttk.Treeview(root, columns=columns, height=5, show='headings')
treeview.pack()
for column in columns:
treeview.heading(column, text=column)
treeview.column(column, width=150)
for i, row in enumerate(data):
treeview.insert('', i, iid=i, text=str(i), values=row)
treeview.selection_set(1)
button = tk.Button(root, text='Delete Item 1', command=button_callback)
button.pack()
treeview.bind("<>", treeview_callback)
root.mainloop()
```
```python
d:\>python test3.py
Python version : 3.8.10
tkinter version: 8.6.9
17:57:43 Treeview selection changed !
d:\>python test3.py
Python version : 3.9.9
tkinter version: 8.6.12
17:58:10 Treeview selection changed !
17:58:11 Treeview selection changed !
d:\>python test3.py
Python version : 3.10.1
tkinter version: 8.6.12
18:01:10 Treeview selection changed !
18:01:12 Treeview selection changed !
```
--
components: Tkinter
messages: 409185
nosy: Jason990420
priority: normal
severity: normal
status: open
title: Delete selected item generate "<>" event or not in
different version of tkinter or Python
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue46179>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46180] Button clicked failed when mouse hover tooltip and tooltip destroyed
New submission from Jason Yang :
Button no response when clicked if mouse move into tooltip and tooltip
destroyed for Python 3.9.9/3.10.1 and tkinter 8.6.12
You can check it by moving mouse into button, then move to tooltip after it
shown, then click button and you won't get response for button clicked, but
"Leave". It is OK for lower version of Python/tkinter.
```python
import sys
from datetime import datetime
import tkinter as tk
class Tooltip(object):
"""
create a tooltip for a given widget
"""
def __init__(self, widget, text='widget info'):
self.waittime = 500 # miliseconds
self.widget = widget
self.text = text
self.widget.bind("", self.enter)
self.widget.bind("", self.leave)
self.widget.bind("", self.leave)
self.id = None
self.top = None
def enter(self, event=None):
print(now(), "Enter")
self.schedule()
def leave(self, event=None):
print(now(), "Leave")
self.unschedule()
self.hidetip()
def schedule(self):
self.unschedule()
self.id = self.widget.after(self.waittime, self.showtip)
def unschedule(self):
id = self.id
self.id = None
if id:
self.widget.after_cancel(id)
def showtip(self, event=None):
x = y = 0
x, y, cx, cy = self.widget.bbox("insert")
x += self.widget.winfo_rootx() + self.widget.winfo_width()//2
y += self.widget.winfo_rooty() + self.widget.winfo_height()//2
self.top = tk.Toplevel(self.widget)
self.top.wm_overrideredirect(True)
self.top.wm_geometry("+%d+%d" % (x, y))
label = tk.Label(self.top, text=self.text, bd=1, font=font,
relief='solid')
label.pack(ipadx=1)
def hidetip(self):
top = self.top
self.top = None
if top:
top.destroy()
def now():
return datetime.now().strftime("%H:%M:%S")
print(f"Python version : {sys.version.split(' ')[0]}")
print(f"tkinter version: {tk.Tcl().eval('info patchlevel')}")
font = ("Courier New", 40)
root = tk.Tk()
button = tk.Button(root, text="button", font=font,
command=lambda:print(now(), 'Button clicked'))
button.pack(padx=10, pady=5)
tooltip = Tooltip(button, 'This is button 1')
root.mainloop()
```
```python
d:\>python test.py
Python version : 3.10.1
tkinter version: 8.6.12
18:21:52 Enter (Mouse to button)
18:21:54 Leave (mouse to tooltip)
18:21:55 Leave (button clicked get no response)
18:21:57 Leave (button clicked get no response)
18:21:58 Leave (button clicked get no response)
d:\>python test.py
Python version : 3.9.9
tkinter version: 8.6.12
18:22:51 Enter (Mouse to button)
18:22:54 Leave (mouse to tooltip)
18:22:55 Leave (button clicked get no response)
18:22:56 Leave (button clicked get no response)
18:22:57 Leave (button clicked get no response)
d:\>python test.py
Python version : 3.8.10
tkinter version: 8.6.9
18:23:22 Enter (Mouse to button)
18:23:23 Leave (mouse to tooltip)
18:23:23 Enter (mouse stay, and it will repeat `Enter and Leave` again and
again)
18:23:24 Leave
...
18:23:28 Enter
18:23:28 Leave
18:23:28 Button clicked (button clicked get response)
18:23:31 Leave
18:23:31 Button clicked (button clicked get response)
18:23:32 Leave
```
Platform - WIN10
--
components: Tkinter
messages: 409188
nosy: Jason990420
priority: normal
severity: normal
status: open
title: Button clicked failed when mouse hover tooltip and tooltip destroyed
type: crash
versions: Python 3.10, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue46180>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46179] Delete selected item generate "<>" event or not in different version of tkinter or Python
Jason Yang added the comment: >From https://core.tcl-lang.org/tk/reportlist, I found the same issue ttk::treeview <> event bug https://core.tcl-lang.org/tk/tktview?name=2a6c62afd9 It is an old bug from 2014 anf not fixed, and now it fixed. OK, no more question about it. Thank you for your information. B.R., Jason Yng -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46210] print deadlocks
New submission from Jason Wilkes : Hi there. :) (First time posting here, so apologies in advance if I'm a goof.) I recently found a deadlock in the stdout and stderr buffer objects. Following the dev guide, I (1) wrote up a patch (2) checked that it fixes the deadlock (on Linux and OS X) (3) made sure it doesn't break any of the cpython tests (on Linux and OS X) But I could use some feedback to make sure the patch isn't doing anything dumb, and to make sure I'm not missing something obvious. Here's the situation. The deadlock only occurs in the sinful state of threading while forking. (I'm aware of the reasons why one should never do that.) But asking newcomers to never mix the two is sort of asking them to know the implementation details of every library they use (these abstractions are leaky). And I like teaching people about python and concurrency, so it would be nice if they didn't have to know all that. So I've recently developed the ill-advised hobby of trying to run as much code as possible in the sinful state of threading while forking, to try to understand which bits of the interpreter and standard library are responsible for most of the deadlocks, in practice. All the non-obvious deadlocks I've encountered seemed to be due to one thing, namely stdout and stderr's buffer->lock not having an _at_fork_reinit. So if a thread is printing during a fork, the child process can never print, else deadlock. Standard hazard of threading and forking. What surprised me was that there didn't seem to be 100s of places in the interpreter where threading and forking don't mix. After fixing this one, all the different thread + fork code I'd been testing worked. Which makes me wonder if there's a reason this hasn't been fixed yet. Hence, maybe the patch is doing something dumb. Anyways, this is sort of a bug report, and sort of a request for comments on how I can make this patch better. Equally cool would be an explanation of why re-initializing that lock is a bad idea to begin with. Thanks for your patience if you read all that. -- components: IO files: example.py messages: 409394 nosy: notarealdeveloper priority: normal severity: normal status: open title: print deadlocks type: behavior versions: Python 3.10, Python 3.11, Python 3.9 Added file: https://bugs.python.org/file50532/example.py ___ Python tracker <https://bugs.python.org/issue46210> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46210] print deadlocks
Change by Jason Wilkes : -- keywords: +patch pull_requests: +28524 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30310 ___ Python tracker <https://bugs.python.org/issue46210> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46180] Button clicked failed when mouse hover tooltip and tooltip destroyed
Jason Yang added the comment: The platform is WIN10 which shown at last line in first message. I don't have other platforms to test if ok or not. -- ___ Python tracker <https://bugs.python.org/issue46180> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46678] Invalid cross device link in Lib/test/support/import_helper.py
New submission from Jason Wilkes : In Lib/test/support/import_helper.py, the function make_legacy_pyc makes a call to os.rename which can fail when the source and target live on different devices. This happens (for example) when PYTHONPYCACHEPREFIX is set to a directory on a different device from where temporary files are stored. Replacing os.rename with shutil.move fixes it. Will submit a PR. -- components: Tests messages: 412791 nosy: notarealdeveloper priority: normal severity: normal status: open title: Invalid cross device link in Lib/test/support/import_helper.py type: behavior versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue46678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46678] Invalid cross device link in Lib/test/support/import_helper.py
Change by Jason Wilkes : -- keywords: +patch pull_requests: +29374 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31204 ___ Python tracker <https://bugs.python.org/issue46678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46679] test.support.wait_process ignores timeout argument
New submission from Jason Wilkes : The function wait_process in Lib/test/support/__init__.py ignores its timeout argument. This argument is useful, for example, in tests that need to determine whether a deadlock has been fixed (e.g., in PR-30310). Will submit a pull request to fix this. -- components: Tests messages: 412793 nosy: notarealdeveloper priority: normal severity: normal status: open title: test.support.wait_process ignores timeout argument type: behavior versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue46679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46679] test.support.wait_process ignores timeout argument
Change by Jason Wilkes : -- keywords: +patch pull_requests: +29375 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31205 ___ Python tracker <https://bugs.python.org/issue46679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46541] Replace _Py_IDENTIFIER() with statically initialized objects.
Change by Jason Wilkes : -- nosy: +notarealdeveloper nosy_count: 7.0 -> 8.0 pull_requests: +29528 pull_request: https://github.com/python/cpython/pull/30310 ___ Python tracker <https://bugs.python.org/issue46541> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46803] Item not shown when using mouse wheel to scroll for Listbox/Combobox
New submission from Jason Yang :
When scrolled items by mouse wheel in tk.Listbox/ttk.Combobox, some items not
shown.
Is it a bug ? or I did something wrong ?
In following case, 'Wednesday' will not shown when scroll mouse wheel at
- tk.Listbox or vertical scrollbar of tk.Listbox, or
- listbox of ttk.Combo
```python
from tkinter import *
from tkinter import ttk
font = ('Courier New', 24)
lst = ('Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday',
'Saturday')
root = Tk()
frame1 = Frame(root)
frame1.pack(side=LEFT)
vsb1 = Scrollbar(frame1, orient='v')
vsb1.pack(side=RIGHT, fill='y')
var = StringVar()
var.set(lst)
listbox = Listbox(frame1, width=10, height=3, listvariable=var, font=font,
yscrollcommand=vsb1.set)
listbox.pack(side=LEFT)
vsb1.configure(command=listbox.yview)
frame2 = Frame(root)
frame2.pack(side=LEFT, fill='y')
combobox = ttk.Combobox(frame2, values=lst, width=10, height=3, font=font)
combobox.pack()
root.mainloop()
```
Platform: WIN10
--
components: Tkinter
files: PeS9r.png
messages: 413564
nosy: Jason990420
priority: normal
severity: normal
status: open
title: Item not shown when using mouse wheel to scroll for Listbox/Combobox
type: behavior
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50634/PeS9r.png
___
Python tracker
<https://bugs.python.org/issue46803>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1000] Patch to rename *Server modules to lower-case
New submission from Jason Prado:
Here's a patcher for the 2to3 fixer. After I add this ticket I'll try to
add another file for the py3k/Lib directory.
--
components: Library (Lib)
files: fixer-server-imports.patch
messages: 55188
nosy: jasonpjason
severity: normal
status: open
title: Patch to rename *Server modules to lower-case
versions: Python 2.6
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1000>
__Index: fixes/fix_imports.py
===
--- fixes/fix_imports.py(revision 57338)
+++ fixes/fix_imports.py(working copy)
@@ -11,9 +11,35 @@
from fixes import basefix
from fixes.util import Name, attr_chain, any, set
-MAPPING = {"StringIO": ("io", ["StringIO"]),
- "cStringIO": ("io", ["StringIO"]),
- "md5": ("hashlib", ["md5"])}
+MAPPING = {"StringIO": ("io", ["StringIO"]),
+ "cStringIO": ("io", ["StringIO"]),
+ "md5": ("hashlib", ["md5"]),
+ "BaseHTTPServer":("base_http_server",
+ ["HTTPServer", "BaseHTTPRequestHandler"]),
+ "SimpleHTTPServer": ("simple_http_server",
+ ["SimpleHTTPRequestHandler"]),
+ "CGIHTTPServer": ("cgi_http_server",
+ ["CGIHTTPRequestHandler"]),
+ "DocXMLRPCServer": ("doc_xmlrpc_server",
+ ["DocXMLRPCServer",
+ "DocCGIXMLRPCRequestHandler",
+ "DocXMLRPCRequestHandler"]),
+ "SimpleXMLRPCServer":("simple_xmlrpc_server",
+ ["SimpleXMLRPCServer",
+ "CGIXMLRPCRequestHandler",
+ "SimpleXMLRPCRequestHandler"]),
+ "SocketServer": ("socket_server",
+ ["TCPServer", "UDPServer",
+ "ForkingUDPServer","ForkingTCPServer",
+ "ThreadingUDPServer", "ThreadingTCPServer",
+ "BaseRequestHandler",
+ "StreamRequestHandler",
+ "DatagramRequestHandler", "ThreadingMixIn",
+ "ForkingMixIn", "UnixStreamServer",
+ "UnixDatagramServer",
+ "ThreadingUnixStreamServer",
+ "ThreadingUnixDatagramServer"]),
+ }
def alternates(members):
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1241] subprocess.py stdout of childprocess always buffered.
New submission from Jason Kim:
Hi.
I am currently using subprocess.py (2.4.4 and above) to try to have a
portable way of running a sub task in linux and windows.
I ran into a strange problem - a program runs and is "timed out"
but the the subprocess's stdout and stderr are not fully "grabbed"
So I've been trying various ways to force "flush" the stdout and stderr
of the child process so that at least partial results can be saved.
The "problem" app being spawned off is very simple:
--
#include
int main() {
int i = 0;
for (i = 0; i < 1000; ++i) {
printf("STDOUT boo %d\n",i);
fprintf(stdout,"STDOUT sleeping %d\n",i);
fprintf(stderr,"STDERR sleeping %d\n",i);
//fflush(stdout);
//fflush(stderr);
sleep(1);
}
}
---
i.e. it just dumps its output to both stdout and stderr. The issue that
I am seeing is that no matter what options I tried to place for
subprocess(), the ONLY output I see from the executed process are
"STDERR sleeping " lines, UNLESS I uncomment the fflush(stdout) line in
the application.
Executing the script with python -u doesn't seem to help either.
Now, if the task completes normally, then I am able to grab the entire
stdout and stderr produced by the subprocess. The issue is that I can't
seem to grab the partial output for stdout, and there does not seem to
be a way to make the file descriptors returned by pipe() to be unbuffered.
So the question is: what is the preferred method of forcing the pipe()
file descriptors created by subprocess.__init__() to be fully unbuffered?
Second, is there a better way of doing this?
i.e. a portable way to spawn off a task, with an optional timeout, grab
any partial results from the task's stdout and stderr, and grab the
return code from the child task?
Any hints and advice will be greatly appreciated.
Thank you.
The relevant snippet of python code is:
import threading
from signal import *
from subprocess import *
import time
import string
import copy
import re
import sys
import os
from glob import glob
from os import path
import thread
class task_wrapper():
def run(s):
if s.timeout > 0:
#print "starting timer for ",s.timeout
s.task_timer = threading.Timer(s.timeout, task_wrapper.cleanup, [s])
s.task_timer.start()
s.task_start_time = time.time()
s.task_end_time = s.task_start_time
s.subtask=Popen(s.cmd, bufsize=0, env=s.env, stdout=PIPE, stderr=PIPE)
s.task_out, s.task_err = s.subtask.communicate()
def kill(s, subtask):
""" attempts a portable way to kill things
First, flush the buffer
"""
print "killing", subtask.pid
sys.stdout.flush()
#s.subtask.stdin.flush()
print "s.subtask.stdout.fileno()=",s.subtask.stdout.fileno()
print "s.subtask.stderr.fileno()=",s.subtask.stderr.fileno()
#os.fsync(s.subtask.stderr.fileno())
#os.fsync(s.subtask.stdout.fileno())
s.subtask.stdout.flush()
s.subtask.stderr.flush()
if os.name == "posix":
os.kill(subtask.pid, SIGKILL)
elif os.name == "nt":
import win32api
win32api.TerminateProcess(subtask._handle ,9)
def cleanup(s, mode="TIMEOUT"):
s.timer_lock.acquire()
if s.task_result == None:
if mode == "TIMEOUT":
s.msg( """ Uhoh, subtask took too long""")
s.kill(s.subtask)
--
messages: 56247
nosy: jason.w.kim
severity: normal
status: open
title: subprocess.py stdout of childprocess always buffered.
type: behavior
versions: Python 2.4, Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1241>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13184] Multi-layered symlinks cause runtime error. sys.path is malformed.
New submission from Jason Howlett : This error is observed in Python 2.7.2. Steps to recreate problem: 1) Create directory ~/pytest. 2) Untar Python 2.7.2 sources into ~/pytest 3) configure, build, and install with --prefix=~/pytest/pyinstall 4) mkdir -p ~/pytest/other/bin 5) cd ~/pytest/other/bin 6) ln -s ../../pyinstall/bin/python 7) cd ~/pytest 8) ln -s other/bin bin 9) bin/python This will result in the following exception: Traceback (most recent call last): File "/home/jason/pytest/bin/../../pyinstall/lib/python2.7/site.py", line 564, in main() File "/home/jason/pytest/bin/../../pyinstall/lib/python2.7/site.py", line 546, in main known_paths = addusersitepackages(known_paths) File "/home/jason/pytest/bin/../../pyinstall/lib/python2.7/site.py", line 279, in addusersitepackages user_site = getusersitepackages() File "/home/jason/pytest/bin/../../pyinstall/lib/python2.7/site.py", line 254, in getusersitepackages user_base = getuserbase() # this will also set USER_BASE File "/home/jason/pytest/bin/../../pyinstall/lib/python2.7/site.py", line 243, in getuserbase from sysconfig import get_config_var ImportError: No module named sysconfig Placing 'print sys.path' on line 242 of site.py prints out something like this: ['/home/jason/pyinstall/lib/python27.zip', '/home/jason/pyinstall/lib/python2.7', '/home/jason/pyinstall/lib/python2.7/plat-linux2', '/home/jason/pyinstall/lib/python2.7/lib-tk', '/home/jason/pyinstall/lib/python2.7/lib-old', '/home/jason/pyinstall/lib/python2.7/lib-dynload'] Notice that the root directory is /home/jason/pyinstall instead of the correct value /home/jason/pytest/pyinstall. Now, on line 65 of site.py, add import sysconfig. For some reason this works at this point in site.py, but not down on line 243. In sysconfig.py, at line 94, add the following: print 'SYSCONFIG:', sys.exec_prefix, _EXEC_PREFIX This will print the following: SYSCONFIG: /home/jason/pytest/bin/../../pyinstall /home/jason/pyinstall Line 93 of sysconfig.py is a call to normpath that collapses the path. The root of this problem is that the value of sys.exec_prefix is not correct. The value it has will work fine if ls'ing it in a shell as it handles the symlink /home/jason/pytest/bin properly. Path calculations internal to python, however, do not end up with the correct results. I believe the fix to this problem is to modify Modules/getpath.c, starting at line 488, and instead of looking only for a symlink in the python executable, also look for a link in any of the path elements leading up to the executable. Detecting and expanding these out should result, in this example, with sys.exec_prefix being /home/jason/pytest/pyinstall and the correct behavior in sysconfig, site, etc. -- components: Interpreter Core messages: 145582 nosy: Jason.Howlett priority: normal severity: normal status: open title: Multi-layered symlinks cause runtime error. sys.path is malformed. type: crash versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue13184> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13184] Multi-layered symlinks to python cause runtime error. sys.path is malformed.
Jason Howlett added the comment: Here is a proposed patch that solves the problem I described. Hopefully someone more familiar with Module/gethpath.c can make sure that it is ok and make improvements if needed. -- keywords: +patch title: Multi-layered symlinks cause runtime error. sys.path is malformed. -> Multi-layered symlinks to python cause runtime error. sys.path is malformed. Added file: http://bugs.python.org/file23415/symlink_path_fix.patch ___ Python tracker <http://bugs.python.org/issue13184> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13184] Multi-layered symlinks to python cause runtime error. sys.path is malformed.
Jason Howlett added the comment: Confirmed. The problem exists in 3.2.2 also. -- ___ Python tracker <http://bugs.python.org/issue13184> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13509] On uninstallation, distutils bdist_wininst fails to run post install script
New submission from Jason Roberts : Historically (i.e. Python 2.6.1 and earlier) bdist_wininst would run the post install script at both installation and uninstallation. The script would be invoked with a -install argument on installation and a -remove argument on uninstallation. This stopped working in Python 2.6.2 and has not worked since. This regression appears to have been introduced in r69094. That checkin rewrote Run_RemoveScript and associated functions in PC/bdist_wininst/install.c. The rewrite changed how the Python DLL was loaded during the remove scenario. Previously Run_RemoveScript itself called Win32 LoadLibrary on the DLL name parsed from the wininst log file. Now Run_RemoveScript calls run_installscript instead, which ultimately calls LoadPythonDll, which calls LoadLibrary on the pythondll global variable. But nothing initializes that variable during the remove scenario and LoadLibrary fails. Ultimately run_installscript silently fails and the removal proceeds to uninstall files and registry keys, with no notification to the user that the post install script was not run. A possible solution is to initialize pythondll in Run_RemoveScript to the DLL name parsed from the wininst log file, e.g. by inserting the following code prior to the call to run_installscript: strncpy(pythondll, dllname, scriptname - 1 - dllname); pythondll[scriptname - 1 - dllname] = '\0'; I tested this and it seemed to work fine. I believe this problem affects all Python releases following and including 2.6.2. The version history seems to show that r69094 was propagated to all of those releases. Presumably nobody found it because post install scripts on removal are not widely used. They are, however, critical for my application (at least if I want it to clean up properly on removal) so I would appreciate this being fixed. As it stands, I have to build a private patched copy of wininst-9.0.exe to work around this problem. -- assignee: tarek components: Distutils messages: 148672 nosy: eric.araujo, jasonjroberts, mhammond, tarek priority: normal severity: normal status: open title: On uninstallation, distutils bdist_wininst fails to run post install script type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue13509> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13276] distutils bdist_wininst created installer does not run the postinstallation script on uninstalling
Jason Roberts added the comment: Sorry, I opened issue13509 after somehow not finding this one. Here is my text from issue13509. Thanks for looking at this problem... Historically (i.e. Python 2.6.1 and earlier) bdist_wininst would run the post install script at both installation and uninstallation. The script would be invoked with a -install argument on installation and a -remove argument on uninstallation. This stopped working in Python 2.6.2 and has not worked since. This regression appears to have been introduced in r69094. That checkin rewrote Run_RemoveScript and associated functions in PC/bdist_wininst/install.c. The rewrite changed how the Python DLL was loaded during the remove scenario. Previously Run_RemoveScript itself called Win32 LoadLibrary on the DLL name parsed from the wininst log file. Now Run_RemoveScript calls run_installscript instead, which ultimately calls LoadPythonDll, which calls LoadLibrary on the pythondll global variable. But nothing initializes that variable during the remove scenario and LoadLibrary fails. Ultimately run_installscript silently fails and the removal proceeds to uninstall files and registry keys, with no notification to the user that the post install script was not run. A possible solution is to initialize pythondll in Run_RemoveScript to the DLL name parsed from the wininst log file, e.g. by inserting the following code prior to the call to run_installscript: strncpy(pythondll, dllname, scriptname - 1 - dllname); pythondll[scriptname - 1 - dllname] = '\0'; I tested this and it seemed to work fine. I believe this problem affects all Python releases following and including 2.6.2. The version history seems to show that r69094 was propagated to all of those releases. Presumably nobody found it because post install scripts on removal are not widely used. They are, however, critical for my application (at least if I want it to clean up properly on removal) so I would appreciate this being fixed. As it stands, I have to build a private patched copy of wininst-9.0.exe to work around this problem. -- versions: +Python 2.6, Python 3.1 ___ Python tracker <http://bugs.python.org/issue13276> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9760] Suggestion for improving with documentation
New submission from Jason Baker :
http://docs.python.org/reference/compound_stmts.html#with
This documentation refers to "context expressions" in two places. However, it
never really defines what a context expression is. The formal syntax that's
presented is this:
with_stmt ::= "with" with_item ("," with_item)* ":" suite
with_item ::= expression ["as" target]
As best I can tell, the context expression is essentially the with_item. If
that's the case, I propose one of the following:
1) The formal syntax is changed so that "with_item" becomes
"context_expression".
2) References to "context expression" change to "with item".
3) The "context expression" is defined to be the with_item in the formal
syntax at some point in the documentation.
--
assignee: d...@python
components: Documentation
messages: 115478
nosy: Jason.Baker, d...@python
priority: normal
severity: normal
status: open
title: Suggestion for improving with documentation
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue9760>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9825] OrderedDict ref cycles cause memory leak
New submission from jason kirtland : Circular graphs of collections.OrderedDict are uncollectable due to the presence of OrderedDict.__del__. >>> from collections import OrderedDict >>> import gc >>> left, right = OrderedDict(), OrderedDict() >>> left['other'] = right >>> right['other'] = left >>> assert not gc.garbage >>> del left, right >>> gc.collect() 10 >>> assert not gc.garbage Traceback (most recent call last): File "", line 1, in AssertionError Not an issue in 3.1.1, have not verified with 3.1.2. -- components: Library (Lib) files: odicttest.py messages: 116036 nosy: jek priority: normal severity: normal status: open title: OrderedDict ref cycles cause memory leak type: resource usage versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file18834/odicttest.py ___ Python tracker <http://bugs.python.org/issue9825> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9826] OrderedDict ref cycles break repr()
New submission from jason kirtland : repr of circular graphs of collections.OrderedDicts fails with 'RuntimeError: maximum recursion depth exceeded while calling a Python object'. >>> from collections import OrderedDict >>> left, right = OrderedDict(), OrderedDict() >>> left['other'] = right >>> right['other'] = left >>> left Traceback (most recent call last): File "", line 1, in ... File "lib/python2.7/collections.py", line 137, in __repr__ return '%s(%r)' % (self.__class__.__name__, self.items()) RuntimeError: maximum recursion depth exceeded in __subclasscheck__ -- components: Library (Lib) files: odictcyclerepr.py messages: 116037 nosy: jek priority: normal severity: normal status: open title: OrderedDict ref cycles break repr() type: behavior versions: Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file18835/odictcyclerepr.py ___ Python tracker <http://bugs.python.org/issue9826> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9825] OrderedDict ref cycles cause memory leak
jason kirtland added the comment: I find the behavior surprising compared to dict and other containers, where this is not an issue and weakrefs are not required in user code. I would not be surprised, however, to have to wait for a gc.collect() to clean up my cycles like I do for regular objects. For what it's worth, the pure-python alternative linked in the docs uses neither __del__ nor weakrefs, though it is undoubtably less efficient than this implementation. And the workaround 'del OrderedDict.__del__' seems to work as well, if one is willing to wait for a gc collection. -- ___ Python tracker <http://bugs.python.org/issue9825> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9849] Argparse needs better error handling for nargs
New submission from Jason Baker :
This is referring to argparse 1.1 installed under Python 2.6. When I was
passing in an nargs flag, I figured that since '+' and '*' are valid options, I
should pass in strings. So when I tried passing in the string '1' instead of
the integer 1, I got the following error:
>>> import argparse
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('foo', nargs='1')
_StoreAction(option_strings=[], dest='foo', nargs='1', const=None,
default=None, type=None, choices=None, help=None, metavar=None)
>>> parser.parse_args()
Traceback (most recent call last):
File "", line 1, in
File "build/bdist.macosx-10.6-universal/egg/argparse.py", line 1698, in
parse_args
File "build/bdist.macosx-10.6-universal/egg/argparse.py", line 1730, in
parse_known_args
File "build/bdist.macosx-10.6-universal/egg/argparse.py", line 1935, in
_parse_known_args
File "build/bdist.macosx-10.6-universal/egg/argparse.py", line 1884, in
consume_positionals
File "build/bdist.macosx-10.6-universal/egg/argparse.py", line 2028, in
_match_arguments_partial
File "build/bdist.macosx-10.6-universal/egg/argparse.py", line 2169, in
_get_nargs_pattern
TypeError: can't multiply sequence by non-int of type 'str'
Fortunately, I had just added the nargs and knew to correct that. However, if
I were to do something like read that value in from a config file and forget to
coerce the value from a string to an int, I could see how this could be a giant
pain to track down.
--
components: Library (Lib)
messages: 116355
nosy: Jason.Baker
priority: normal
severity: normal
status: open
title: Argparse needs better error handling for nargs
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue9849>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5755] "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++"
Jason Grout added the comment: Any progress on this? I see this warning a *lot* when compiling lots of packages for Sage (matplotlib included). -- nosy: +Jason.Grout ___ Python tracker <http://bugs.python.org/issue5755> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10034] Readline doc issue
New submission from Jason Baker : There's an error in the documentation for readline here: http://docs.python.org/library/readline.html#example The first example doesn't import readline. -- assignee: d...@python components: Documentation messages: 118040 nosy: Jason.Baker, d...@python priority: normal severity: normal status: open title: Readline doc issue versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue10034> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10046] Correction to atexit documentation
New submission from Jason Baker : There's an issue with the documentation on the atexit module[1]. It states: "Note: the functions registered via this module are not called when the program is killed by a signal, when a Python fatal internal error is detected, or when os._exit() is called." This isn't necessarily true. For instance, if I start the following script: from atexit import register from time import sleep @register def end(): print 'atexit' while True: sleep(1) ...and then do a "kill -SIGINT ", the atexit function gets called. It would be helpful to have a more detailed description of the rules on how this works. [1] http://docs.python.org/library/atexit.html#module-atexit -- assignee: d...@python components: Documentation messages: 118141 nosy: Jason.Baker, d...@python priority: normal severity: normal status: open title: Correction to atexit documentation versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue10046> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10046] Correction to atexit documentation
Jason Baker added the comment: I like that phrasing. I think it would be a good idea to mention that this includes SIGINT by default, just to be explicit. -- ___ Python tracker <http://bugs.python.org/issue10046> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11722] mingw64 does not link when building extensions
New submission from Jason Morgan :
Bulding a simple extension (the spam example) fails with mingw64.
in modsupport.h, the following is used to detect 64bit, it does not work with
mingw64.
#if SIZEOF_SIZE_T != SIZEOF_INT
/* On a 64-bit system, rename the Py_InitModule4 so that 2.4
modules cannot get loaded into a 2.5 interpreter */
#define Py_InitModule4 Py_InitModule4_64
#endif
This code never compiles, you can test this by placing similar code and filling
it with rubbish.
This means it thinks the extension is being built on a 32bit compiler and
creates the wrong call for Py_InitModule.
Workaround:
Explicitly calling Py_InitModule4_64() in extension and declaring
Py_InitModule4_64(...) in code. Note this does not complain about
re-declaration and builds OK because declaration is wrong.
e.g.
//m=Py_InitModule("spam", SpamMethods);
m = Py_InitModule4_64("spam", SpamMethods,(char *)NULL, (PyObject *)NULL,
PYTHON_API_VERSION);
Or, a better more portable permanent fix, define WIN64 in code and
modify modsupport.h:
#if SIZEOF_SIZE_T != SIZEOF_INT || defined(WIN64)
/* On a 64-bit system, rename the Py_InitModule4 so that 2.4
modules cannot get loaded into a 2.5 interpreter */
#define Py_InitModule4 Py_InitModule4_64
#endif
I am sure there are other, more standard ways.
--
components: Extension Modules
messages: 132595
nosy: moog
priority: normal
severity: normal
status: open
title: mingw64 does not link when building extensions
type: compile error
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue11722>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11723] No proper support for mingw64 - patch to add
New submission from Jason Morgan : Python2.7 has no proper support for mings64. You can use environment path to trick compiler into using mings64, but this will cause conflict with other builds. Adding a mings64 compiler options is much more sensible as both mingw32 and mings64 can co-exist. (mingw64 has a prefix for all it's exe's) Suggest following patch, tested with mingw-w64-1.0-bin_i686-mingw_20110328 and Python-2.7.1(x64) on Windows7. Diff attached. See related issue 11722 -- components: Extension Modules files: mingw64.diff keywords: patch messages: 132597 nosy: moog priority: normal severity: normal status: open title: No proper support for mingw64 - patch to add type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file21477/mingw64.diff ___ Python tracker <http://bugs.python.org/issue11723> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11723] No proper support for mingw64 - patch to add
Jason Morgan added the comment: Ok, I know there is a typo, (mings64 should read mingw64) I realised after posting but can't edit it. I don't need any more emails telling me I can't spell (or type) - I knew that already! -- ___ Python tracker <http://bugs.python.org/issue11723> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11722] mingw64 does not link when building extensions
Jason Morgan added the comment: OK, I've understood this a bit more. The compiler does not cause pyconfig.h to define SIZEOF_SIZE_T and SIZEOF_INT, rather it is the definition of MS_WIN64 at compile time (which was not being defined) Defining MS_WIN64 fixes the problem, and causes another unrelated one I would guess that I would have to change the patch in Issue11723 to define MS_WIN64, how do I then use the same compiler for 32BIT? What is the correct way to pass such flags to the compiler class? -- ___ Python tracker <http://bugs.python.org/issue11722> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1449496] Python should use 3GB Address Space on Windows
Jason Scheirer added the comment: The patch is a simple tweak to the Visual Studio project's compiler settings. Seems quite innocuous, nothing broke in the Python harness or our internal harnesses (at ESRI) by enabling this. -- keywords: +patch nosy: +Jason.Scheirer status: pending -> open Added file: http://bugs.python.org/file20083/Issue1449496.diff ___ Python tracker <http://bugs.python.org/issue1449496> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1449496] Python should use 3GB Address Space on Windows
Jason Scheirer added the comment: I would like to see this reopened: we have a very large class of users that are not ready to entirely port to 64-bit and need this now. When running a Python script from within a desktop application (which embeds Python and has /LARGEADDRESSAWARE set) or outside in Python.exe (which does not) results in the outputs from the tools calling out to these 32 bit libraries to produce different outputs because the amount of data they are able to allocate and process at the same time. The same Python script that gives correct output on a large dataset in this desktop app will not yield the same quality of results when run overnight as a stand-alone Python script. Essentially this discounts Python scripts as an option for automation in this case. I understand that yes, applications still cannot allocate more CONTIGUOUS memory, but this is not a regression if it continues to be so. Allowing the process to allocate more TOTAL memory is a net benefit, especially on on complex software systems that can't simply be rebuilt in 64 bit mode due to third-party restraints (tied to a specific library version, lack of access to source, lengthy software approvals processes, etc.) -- ___ Python tracker <http://bugs.python.org/issue1449496> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11011] More functools functions
New submission from Jason Baker : I've created a patch that adds some common functional programming tools to functools. I've made the patch to work against Python 3.2, but that may be a bit aggressive. If so, then I can adapt it to work with 3.3. I also wouldn't be opposed to writing some of these in C if there's a performance need. The functions I added are: * flip - flip the first two arguments of a function * const - return a function that always returns the same thing * compose - compose multiple functions together * identity - returns what is passed in to it * trampoline - calls a function and then calls any returned functions. -- components: Library (Lib) files: functools.patch keywords: patch messages: 127062 nosy: Jason.Baker priority: normal severity: normal status: open title: More functools functions versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file20520/functools.patch ___ Python tracker <http://bugs.python.org/issue11011> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11011] More functools functions
Jason Baker added the comment: Ray, thanks for prompt and thorough feedback. To address your concerns: * I'm fine with doing away with const and identity (long story short I haven't really used them in functional languages anyway). There were reasons for defining identity the way it is, but it's hardly a big deal if that doesn't make it in. * Personally, I see the mathematical notation for compose to be very intuitive, however it's typically described in a non-intuitive manner. The functions get called in a left-to-right manner (as is intuitive), however, when you see it defined it is usually in a right-to-left manner. Thus it can be confusing because we say compose(f, g)(x) [left-to-right] is equivalent to g(f(x)) [which reads right-to-left, but is still doing what you might expect intuitively]. But I doubt most people that use Python will care about the mathematical usage anyway. What if we called the function "pipeline"? That's essentially what it's doing, and I think people would find that easier to understand. * I'm not saying you're wrong about trampoline, but I want to make sure that you and I are discussing the same thing. :-) The idea for trampoline comes from clojure, which is unique among functional languages in that it has no tail-call recursion. Trampoline is a way to write a function that is tail recursive, but won't blow the stack. So your example, while similar isn't *quite* the same thing. The documentation I wrote shows an example function count_to_a_million. If I wrote it like this I'd blow the stack: def count_to_a_million(i): if i < 100: return count_to_a_million(i) else: return i Of course, you could definitely argue that it would just be easier to use a loop (or even better range). However, many functional programmers' brains have just been wired to use recursion which they might find more intuitive as a means of iteration. Of course, one could argue that it would be better for them to learn the Pythonic way of doing things, and I would agree. Python is a multi-paradigm language that supports both functional and imperative approaches, therefore it's Pythonic to provide a functional approach. * It sounds like you feel flip is useful, but it's a matter of whether you feel it's useful enough to add to the standard library. Lastly, I love list comprehensions and see where you're coming from, but why do the two have to be mutually exclusive? I mean, the idea for them came from Haskell which hasn't done away with them. For instance, take your example: [f(g(2,x), h(x, 3, y, flag=True)) for x, y in zip(X, Y) if x>y//2] I certainly hope you don't really write code like that. :-) I think something like this is more readable: fg = partial(compose(f, g), 2) h1 = lambda x, y: h(x, 3, y, flag=True) [(fg(x), h1(x, y)) for x, y in zip(X, Y) if x>y//2] ...but maybe I'm weird. If you're still opposed to adding these functions, let me know. I feel that they have use-cases in the Python standard library, but I can add them to pysistence when I port it to Python 3 and make it a functional data structure/algorithm library. :-) -- ___ Python tracker <http://bugs.python.org/issue11011> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11011] More functools functions
Jason Baker added the comment: I'm not sure I understand how Raymond's alternative for trampoline works. Let's take the factorial algorithm from wikipedia's page on tail recursion[1]. I've implemented the tail recursive version of the algorithm in Python using trampoline: from functools import trampoline, partial def factorial(n): def fact(i, acc): if i: return partial(fact, (i-1), (acc * i)) else: return acc return trampoline(fact, n, 1) >>> factorial(5) 120 How would I implement this using Raymond's alternative? [1] http://en.wikipedia.org/wiki/Tail_call#Example_programs -- ___ Python tracker <http://bugs.python.org/issue11011> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3039] tarfile.TarFileCompat.writestr(ZipInfo, str) raises AttributeError
New submission from Jason Kankiewicz <[EMAIL PROTECTED]>:
tarfile.TarFileCompat.writestr( self, zinfo, bytes ) raises
AttributeError("'ZipInfo' object has no attribute 'name'") because an
analog to the tarfile.TarInfo.name attribute cannot be monkeypatched
into the zinfo argument value when it's an instance of zipfile.ZipInfo.
The zipfile.ZipInfo class' attributes are slots, so no ad hoc attributes
can be monkeypatched into an instance of it.
I've replaced the monkeypatching of zinfo with the creation of a new
tarfile.TarInfo object, tinfo, which receives its relevant values instead.
This revealed another problem with the assignment of zinfo.file_size to
tinfo.size: if zinfo.file_size has not been assigned a value then an
AttributeError("file_size") will be raised because the slotted attribute
doesn't exist.
Being that the documentation for zipfile.ZipFile.writestr( self,
zinfo_or_arcname, bytes ) claims that a zipfile.ZipInfo object value for
zinfo_or_arcname must contain "at least the filename, date and time",
it's highly likely that zinfo.file_size will be unassigned in ordinary use.
I fixed this problem by ignoring the value of zinfo.file_size and using
the value of len(bytes) instead, just like the implementation of
zipfile.ZipFile.writestr.
I would have provided a patch for tarfile.TarFileCompat.writestr's unit
test suite, but it doesn't appear to exist.
--
components: Library (Lib)
files: tarfile.TarFileCompat.patch
keywords: patch
messages: 67708
nosy: jkankiewicz
severity: normal
status: open
title: tarfile.TarFileCompat.writestr(ZipInfo, str) raises AttributeError
type: crash
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10520/tarfile.TarFileCompat.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3039>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2234] cygwinccompiler.py fails for latest MinGW releases.
Jason Tishler <[EMAIL PROTECTED]> added the comment: There have been three different regular expressions proposed to resolve this issue: 1. http://bugs.python.org/issue2234 2. http://bugs.python.org/issue3013 3. http://cygwin.com/ml/cygwin/2008-05/msg00622.html Does anyone know which one is best? I would like to release a patched Cygwin Python 2.5.2 that resolves this issue, but I feel we should reach consensus on what regular expression to use before I do so. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2234> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2234] cygwinccompiler.py fails for latest MinGW releases.
Jason Tishler <[EMAIL PROTECTED]> added the comment: I tested the regular expression in #3: (\d+\.\d+(\.(\d+))?([ab](\d+))?) and it worked for both '2.18.50.20080523' & '1.2.3a'. Additionally, it worked for the following test cases that I tried: 2.18.50a.20080523 2.18.50a 20080523 2.18.50 20080523 1.2.3 Unfortunately, I don't know what is the set of all possible version formats that "ld -v" can return. So, I don't know how to devise a regular expression guaranteed to work for all ld versions including future ones. AFAICT, we have only two options to resolve this issue: 1. Improve the regular expression as best we can and continue to change it as necessary in the future. 2. Remove the fragile version checking all together and make an explicit decision to only support modern binutils. Any opinions? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2234> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2234] cygwinccompiler.py fails for latest MinGW releases.
Jason Tishler <[EMAIL PROTECTED]> added the comment: cygwinccompiler.py only uses the first group: $ fgrep group cygwinccompiler.py gcc_version = StrictVersion(result.group(1)) ld_version = StrictVersion(result.group(1)) dllwrap_version = StrictVersion(result.group(1)) So, I would like to move forward with the regular expression from http://cygwin.com/ml/cygwin/2008-05/msg00622.html: (\d+\.\d+(\.(\d+))?([ab](\d+))?) Can we get a consensus? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2234> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3169] email/header.py doesn't handle Base64 headers that have been insufficiently padded.
New submission from Jason Williams <[EMAIL PROTECTED]>: email/header.py:decode_header() Line 95: dec = email.base64mime.decode(encoded) Headers that contain Subject or From headers which are Base64 encoded and are insufficiently padded raise a HeaderParseError. The actual padding error is begin generated in binascii.a2b_base64 and bubbling up as a HeaderParseError in header.py. decode_header() should detect the padding error (Base64 text length does not evenly divide by 3) and automatically add padding before handing off to a2b_base64. The problem usually occurs with spam. Example problem header: Subject: =?iso-8859-1?B? UHJldmVudCBGb3JlY2xvc3VyZSAmIFNhdmUgWW91ciBIb21lIA=?= Properly Padded: Subject: =?iso-8859-1?B? UHJldmVudCBGb3JlY2xvc3VyZSAmIFNhdmUgWW91ciBIb21lIA==?= -- components: Library (Lib) messages: 68553 nosy: jasonjwwilliams severity: normal status: open title: email/header.py doesn't handle Base64 headers that have been insufficiently padded. type: behavior versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3169> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable
New submission from Jason Spiro <[EMAIL PROTECTED]>: The Python Windows installer[1] should automatically add the Python and Scripts directories to the PATH environment variable. (If you like, you can also provide a checkbox in the installer GUI that users can uncheck if they don't want this behavior.) This issue was discussed at http://nabble.com/Why-does-Python-never-add- itself-to-the-Windows-path--td8044465.html and the majority consensus was that this is a good idea, but nobody has volunteered to implement it. ^ [1]. The installer is generated by the code at http://svn.python.org/view/python/trunk/Tools/msi/ -- components: Installation, Windows messages: 71172 nosy: christian.heimes, jasonspiro, loewis severity: normal status: open title: Windows installer should add Python and Scripts directories to the PATH environment variable type: feature request ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable
Jason Spiro <[EMAIL PROTECTED]> added the comment: Martin, at the time I read the python-list thread, I didn't pay any attention to the posts' authors. Only now did I realize you were one of the posters. Oops. I already know the basic ideas about creating MSIs with Wise from a past job. So now I researched and thought about this particular problem for several hours. I've learned that Windows Installer is able to add ...\python and ...\python\scripts to the PATH during installation. It cannot[1] remove them at uninstallation. [ WiX, and its superior competitor MAKEMSI, each provide slightly higher-level abstractions[2][3] on top of what Windows Installer provides[4] to make this slightly easier, but not by that much. But I will assume you don't plan to spend days or weeks of your spare time on migrating away from msilib. :-) ] Here are the rough notes I've made up so far on how to do this: - make a new method add_environment. In it: - call start_component to create components "modify_path_per_user" and "modify_path_per_machine" - call add_data to create an Environment table. It should have two rows[5]: - Name:"=PATH" Value:"[TARGETDIR];[TARGETDIR]\Scripts;[~]" Component:"modify_path_per_user" - Name:"=*PATH" Value:"[TARGETDIR];[TARGETDIR]\Scripts;[~]" Component:"modify_path_per_machine" Another difficult part is the UI. Then there's the issue of switching which of the two components are installed based on whether it's per- user or per-machine and also based on whether the user specifies via the UI that they want their PATH changed. I have to think more about that, and I'm already tired of researching. Remember that Windows Installer cannot undo its PATH changes at uninstall time. So, before I consider proceeding further, let me verify a few things with you. 1. [TARGETDIR] will stay on the path. I think that is fine, since the python.exe will be gone, so will never be executed. Do you agree? 2. [TARGETDIR]\scripts will also stay on the path. And it may still contain scripts installed by the user or by third-party installers like the SCons installer. I don't know enough about how Python works to know if that's a problem. Is it a problem? P.S. Would you prefer to discuss this by something more synchronous like telephone (I will pay the tolls) or instant messaging? P.P.S. Now that I have realized how complicated Python installation actually is, and how hard it is to design the tables of and write raw .MSI files, I have a new appreciation for the work you've done on making a Python MSI installer. Thank you very much for having done so. Also, now that I have started researching how much work is necessary to get this done, I realize why you don't want to code it yourself. :-) I don't know if I will end up actually managing to come up with a patch. ^ [1]. I have inferred this fact based on http://www.isg.ee.ethz.ch/tools/realmen/det/msi.en.html -- scroll down to the "Setting the PATH" section ^ [2]. http://blogs.technet.com/alexshev/archive/2008/03/28/from-msi- to-wix-part-13-installable-items-environment-variable.aspx ^ [3]. http://makemsi-manual.dennisbareis.com/path.htm ^ [4]. http://msdn.microsoft.com/en-us/library/aa368369(printer).aspx ^ [5]. Search inside the page http://msdn.microsoft.com/en- us/library/aa368369(printer).aspx for "If the package can be installed per-user or per-machine" to see why you need two rows. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2234] cygwinccompiler.py fails for latest MinGW releases.
Jason Tishler <[EMAIL PROTECTED]> added the comment: Thanks! ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2234> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3621] it would be nice if installers made by bdist_wininst stored an EstimatedSize property in the Windows registry
New submission from Jason Spiro <[EMAIL PROTECTED]>: == Summary == Installers made by bdist_wininst never set EstimatedSize in the Windows registry. So Windows makes an estimate[1] of the installed software's size so the Add/Remove Programs control panel can tell users how much space the software is are taking up. Windows overestimates the size: it estimates the size as equal to the size of the entire C:\Python directory. Nowadays, disk space is cheaper than ever, so I assume it's uncommon for people to try to uninstall software to gain space back. So I do not think it's worth fixing this bug. Does anyone think it *is* worth fixing? == Steps to repro == You *must* be running Windows XP or higher to repro this.[2] I used Python 2.5 (which I installed using the MSI installer) but I would be extremely surprised if this was already fixed in a newer Python's distutils. - Download the attached testcase.zip - Unzip it to a temp directory - From the temp directory, run the commands: setup.py bdist_wininst cd dist foo-1.0.win32.exe - Click on Start Menu > Settings > Control Panel > Add/Remove Programs - Scroll down to "Python 2.5 foo-1.0". == Actual results == - The "Size" column on the right says 46.86MB (that's the size of my entire "C:\Python 2.5" directory.) == Expected results == - The "Size" column on the right should say something close to 0.1 megabytes. == Suggested fix == - When creating an installer, bdist_wininst should look at the total size of all files to install, multiply that number by 3 (a reasonable estimate of the total size the .pyc and .pyo files will take up), and make the installer set the EstimatedSize[3] in the registry to that number. == Footnotes == ^ [1]. See the blog entry "How does Add/Remove Programs get the size and other information?" by Raymond Chen at http://blogs.msdn.com/oldnewthing/archive/2004/07/09/178342.aspx for info on the algorithm Windows uses. ^ [2]. Versions of Windows older than XP never try to estimate the size of installed programs. ^ [3]. This is HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\(application descriptor)\EstimatedSize and should be a DWORD representing the number of kilobytes the software takes up, according to http://forum.installsite.net/?showtopic=698#entry12501 -- components: Distutils messages: 71554 nosy: jasonspiro severity: normal status: open title: it would be nice if installers made by bdist_wininst stored an EstimatedSize property in the Windows registry type: feature request ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3621] it would be nice if installers made by bdist_wininst stored an EstimatedSize property in the Windows registry
Jason Spiro <[EMAIL PROTECTED]> added the comment: Attaching testcase. It's basically just some sample code from the distutils documentation. Added file: http://bugs.python.org/file11177/testcase.zip ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706863] Failed to build Python 2.5.1 with sqlite3
Jason Tishler <[EMAIL PROTECTED]> added the comment: The Cygwin build is having the same problem: http://cygwin.com/ml/cygwin/2008-09/msg00145.html In this case, the sqlite3 libraries are installed (in /usr/lib), but their suffixes do not match the expected values. Does anyone know the best way to make setup.py and/or distutils search for .dll.a instead of .dll? -- nosy: +jlt63 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1706863> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3915] Broken link in 14.7 curses, Python Library Reference
New submission from Jason Etheridge <[EMAIL PROTECTED]>: In http://docs.python.org/lib/module-curses.html, the link "Curses Programming with Python" is broken. It links to http://www.python.org/doc/howto/curses/curses.html, which no longer exists. I found the page externally at http://www.amk.ca/python/howto/curses/. -- assignee: georg.brandl components: Documentation messages: 73469 nosy: georg.brandl, jasoneth severity: normal status: open title: Broken link in 14.7 curses, Python Library Reference type: behavior versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3915> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3935] bisect insort C implementation ignores methods on list subclasses
New submission from jason kirtland <[EMAIL PROTECTED]>: The C implementation (only) of bisect does not invoke list subclass methods when insorting. Code like this will not trigger the assert: class Boom(list): def insert(self, index, item): assert False bisect.insort(Boom(), 123) object-derived classes are OK. -- components: Library (Lib) files: test.py messages: 73589 nosy: jek severity: normal status: open title: bisect insort C implementation ignores methods on list subclasses type: behavior versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file11561/test.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3935> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706863] Failed to build Python 2.5.1 with sqlite3
Jason Tishler <[EMAIL PROTECTED]> added the comment: The Cygwin build issue was worked around by releasing a sqlite3 package that contains a static library too. However, this causes the Python _sqlite module to be statically linked against sqlite3 even though a shared library version is available. The following patch enables Cygwin to leverage off on the ".dylib" functionality added (AFAICT) for Mac OS X. After the patch is applied, the _sqlite module is linked against the shared sqlite3 library instead of the static one. Is the patch acceptable? Or, can someone think of a better approach? Added file: http://bugs.python.org/file11575/unixccompiler.py.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1706863> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706863] Failed to build Python 2.5.1 with sqlite3
Jason Tishler <[EMAIL PROTECTED]> added the comment: Hirokazu Yamamoto wrote: > Python is not using CCygwinCCompiler to build itself on cygwin. Which I why my patch modifies UnixCCompiler instead of CCygwinCCompiler. FWIW, my patch leverages the already existing Cygwin specific code in UnixCCompiler. So, is my patch acceptable? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1706863> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2445] Use The CygwinCCompiler Under Cygwin
Jason Tishler <[EMAIL PROTECTED]> added the comment: I don't think the patch, cygwin-smaller.diff, is correct. The value of static_lib_extension needs to remain ".a". Otherwise, shared extensions attempting to build against a library that only offers a static version will fail to link. AFAICT, Cygwin needs a concept that is not currently supported by distutils -- the ability to specify a shared library *link* extension (i.e., ".dll.a") which is different from the shared library extension (i.e., ".dll"). On Unix they are the same (e.g., ".so"), but on Cygwin they are different because of how Windows handles DLLs -- import library versus DLL. -- nosy: +jlt63 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2445> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706863] Failed to build Python 2.5.1 with sqlite3
Jason Tishler <[EMAIL PROTECTED]> added the comment: Hirokazu Yamamoto wrote: > Umm, it works, but I'm not sure we can call import library as > dylib... Agreed. > I had considered attached patch "experimental_distutils.patch". > It's little adhoky, I'm not sure this patch is acceptable. The new functionality is very similar to what I suggested in issue2445. Although it would be better to put Cygwin specific behavior in CygwinCCompiler, I think the changes would have be more invasive if you did. I prefer your approach to mine. Can we get consensus and move forward? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1706863> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4071] ntpath.abspath can fail on Win Server 2008 (64-bit)
New submission from Jason Day <[EMAIL PROTECTED]>: On my system (Windows Server 2008 SP1 - 64-bit, Python 2.5.2 - 32-bit), simple actions like: >>> help(help) # Or any function or >>> import tempfile >>> f = tempfile.mktemp() result in this (rather confusing) error: TypeError: _getfullpathname() argument 1 must be (buffer overflow), not str Apparently, _getfullpathname() chokes on certain paths if they are not supplied as unicode. Locally, I was able to work around the issue by changing the call to _getfullpathname in ntpath.abspath to: path = str(_getfullpathname(unicode(path))) -- components: Windows messages: 74502 nosy: JDay severity: normal status: open title: ntpath.abspath can fail on Win Server 2008 (64-bit) type: crash versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4071> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4071] ntpath.abspath can fail on Win Server 2008 (64-bit)
Jason Day <[EMAIL PROTECTED]> added the comment: Running help() or mktemp() causes _getfullpathname to be called with the whole system path (791 characters). If you pass that to _getfullpathname as str it throws the aforementioned TypeError. If it's passed as unicode, it returns an empty string. The offending _getfullpathname call occurs on the first call to one of these methods. Future calls to either do not call it (unless, of course, the first failed). ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4071> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4071] ntpath.abspath can fail on Win Server 2008 (64-bit)
Jason Day <[EMAIL PROTECTED]> added the comment: > I am not sure to understand. Do you mean the whole PATH environment > variable? I doubt that it is passed to _getfullpathname. > Or do you have very long paths for one directory? the TEMP environment > variable, for example? I'd be curious to see its value. I don't have it offhand, but it was the whole PATH environment variable, complete with semicolons. That's probably the *real* bug. Whatever was passing that into abspath didn't seem to mind getting back an empty string (although that may have been further processed in the function, I didn't follow past the call to _getfullpathname). > And one decision problem... What should we do when too long str is > passed to ntpath._getfullpathname? Report overflow error? Or convert to > unicode and retry with GetFullPathNameW? Hmm abspath should be able to be called with str or unicode of arbitrary lengths. Consumers of it shouldn't have to be concerned with the platform implementation when it can be smoothed over by the module. Whether this is done in abspath or _getfullpathname probably isn't too important, since end-users generally shouldn't be calling _getfullpathname, directly. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4071> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4071] ntpath.abspath fails for long str paths
Changes by Jason Day <[EMAIL PROTECTED]>: -- title: ntpath.abspath can fail on Win Server 2008 (64-bit) -> ntpath.abspath fails for long str paths ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4071> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4071] ntpath.abspath can fail on Win Server 2008 (64-bit)
Jason Day <[EMAIL PROTECTED]> added the comment: > Indeed. Do you happen to have the complete traceback of the failing > tempfile.mktemp() call? I don't see where it can use the PATH > environment variable. The problem was that somehow, on our systems, the TEMP environmental variable had been copied over with PATH. Most likely some batch file tried to store a copy of PATH, without realizing the significance of TEMP. [groan] Anyway, I still think that it's a bug that abspath() can't be called with a perfectly good str path, because of limitations with the windows api. I edited the bug title to reflect the actual bug. The str path length could be checked and upgraded to the Unicode version, if necessary (or try again with the unicode version, in the case of an exception). I think it's important to ensure that when abspath() is called with str, it returns str, even if it was upgraded to the unicode call. -- title: ntpath.abspath fails for long str paths -> ntpath.abspath can fail on Win Server 2008 (64-bit) ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4071> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4071] ntpath.abspath fails for long str paths
Changes by Jason Day <[EMAIL PROTECTED]>: -- title: ntpath.abspath can fail on Win Server 2008 (64-bit) -> ntpath.abspath fails for long str paths ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4071> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1005895] curses for win32
Jason Tishler added the comment: Sorry, but I don't know. I haven't looked at this issue for almost five years! And when I did, I only looked as far to determine it wasn't Cygwin related. -- ___ Python tracker <http://bugs.python.org/issue1005895> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8261] License link for Python 2.6.5 release is broken
New submission from Jason Mobarak : The 'Python License' link at http://www.python.org/download/releases/2.6.5/ results in a 404. -- assignee: georg.brandl components: Documentation messages: 101894 nosy: georg.brandl, silverjam severity: normal status: open title: License link for Python 2.6.5 release is broken versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue8261> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8581] Logging handlers do not handle double-closing very well
New submission from Jason Baker : The logging handler does not handle double-closing very well: >>> from logging import StreamHandler >>> h = StreamHandler() >>> h.close() >>> h.close() Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.6/logging/__init__.py", line 705, in close del _handlers[self] KeyError: There are two possible approaches to this: 1. Raise a better error. 2. Ignore the duplicate close. This patch takes option 2 as this is likely not indicative of any kind of programmer error, but it shouldn't be too difficult to take option 1 instead. -- components: Library (Lib) messages: 104662 nosy: Jason.Baker priority: normal severity: normal status: open title: Logging handlers do not handle double-closing very well type: behavior versions: Python 2.6, Python 3.1 ___ Python tracker <http://bugs.python.org/issue8581> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8581] Logging handlers do not handle double-closing very well
Jason Baker added the comment: Adding patch -- keywords: +patch Added file: http://bugs.python.org/file17151/logging.patch ___ Python tracker <http://bugs.python.org/issue8581> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8582] urllib.urlretrieve fails with ValueError: Invalid format string
New submission from Jason Gross : When calling urllib.urlretrieve with a data:image/png url (possibly with other urls too) and a local file name, it fails with Traceback (most recent call last): File "", line 1, in urlretrieve(url, file_name) File "D:\Python26\Lib\urllib.py", line 93, in urlretrieve return _urlopener.retrieve(url, filename, reporthook, data) File "D:\Python26\Lib\urllib.py", line 237, in retrieve fp = self.open(url, data) File "D:\Python26\Lib\urllib.py", line 205, in open return getattr(self, name)(url) File "D:\Python26\Lib\urllib.py", line 596, in open_data time.gmtime(time.time( This can be fixed by replacing %T on line 595 with %H : %M : %S (which I found as the definition of %T on http://www.opengroup.org/onlinepubs/009695399/functions/strftime.html) -- components: Library (Lib) messages: 104664 nosy: Jason.Gross priority: normal severity: normal status: open title: urllib.urlretrieve fails with ValueError: Invalid format string type: crash versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue8582> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8581] Logging handlers do not handle double-closing very well
Jason Baker added the comment: Vinay, I don't necessarily disagree with you. However, this appears to be a pretty trivial change. If there is a 2.6.6, I think this should go in it. -- ___ Python tracker <http://bugs.python.org/issue8581> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8690] multiprocessing.dummy.Queue does not expose same interface as multiprocessing.Queue
New submission from Jason Baker : The multiprocessing.dummy.Queue class is merely an import of Queue.Queue. There are a few methods that this does not provide however: close, join_thread, and cancel_join_thread. I don't know what the best way to handle this is, but it should be pretty trivial to add methods that do nothing or at least throw a NotImplementedError. -- components: Library (Lib) messages: 105533 nosy: Jason.Baker priority: normal severity: normal status: open title: multiprocessing.dummy.Queue does not expose same interface as multiprocessing.Queue versions: Python 2.6, Python 2.7 ___ Python tracker <http://bugs.python.org/issue8690> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3621] it would be nice if installers made by bdist_wininst stored an EstimatedSize property in the Windows registry
Jason Spiro added the comment: > Can you provide a patch? Unfortunately not. I still don't think it's worth fixing this bug. :) I think you should document it in the bdist_wininst documentation then close this bug as "won't fix due to lack of volunteer resources". That way the problem will be documented both here and in that documentation, but nobody need spend the time to fix such a minor bug. Or at least you should lower this bug's priority to the lowest setting. -- ___ Python tracker <http://bugs.python.org/issue3621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2045] defaultdict subclasses segfault with a bound method set as a default_factory
New submission from jason kirtland: Python 2.5.1 (r251:54863, May 23 2007, 16:25:53) [GCC 4.1.1 20070105 (Red Hat 4.1.1-52)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from collections import defaultdict >>> class sub(defaultdict): ... def __init__(self): ... self.default_factory = self._factory ... def _factory(self): ... return [] ... >>> s = sub() >>> repr(s) Segmentation fault -- components: Library (Lib) messages: 62185 nosy: jek severity: normal status: open title: defaultdict subclasses segfault with a bound method set as a default_factory type: crash versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2045> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2233] Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail
New submission from Jason Tishler: Makefile.pre.in contains extra slash before $(DESTDIR) in two locations as in the following: sharedinstall: $(RUNSHARED) ./$(BUILDPYTHON) -E $(srcdir)/setup.py install \ --prefix=$(prefix) \ --install-scripts=$(BINDIR) \ --install-platlib=$(DESTSHARED) \ --root=/$(DESTDIR) This causes Cygwin builds to fail if DESTDIR is set as follows: creating //tmp error: could not create '//tmp': No such host or network path The following Open Group Specification: http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html indicates the following: 4.11 Pathanme Resolution [snip] A pathname that begins with two successive slashes may be interpreted in an implementation-defined manner,... IMO, these extra slashes should be removed as indicated in the attached patch. OK to commit? If so, to which branches? -- assignee: jlt63 components: Build files: python.patch keywords: patch, patch messages: 63256 nosy: jlt63 priority: low severity: normal status: open title: Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail type: compile error versions: Python 2.5 Added file: http://bugs.python.org/file9603/python.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2233> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2233] Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail
Changes by Jason Tishler: __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2233> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2235] __eq__ / __hash__ check doesn't take inheritance into account
New submission from jason kirtland:
In 2.6a, seems like the __hash__ implementation and __eq__ must be
defined together, in the same class. See also #1549. Ensuring that a
__hash__ implementation isn't being pulled from a builtin type is
probably a sufficient check...?
>>> class Base(object):
... def __init__(self, name):
... self.name = name
... def __eq__(self, other):
... return self.name == other.name
... def __hash__(self):
... return hash(self.name)
...
>>> class Extended(Base):
... def __eq__(self, other):
... print "trace: __eq__ called"
... return Base.__eq__(self, other)
...
>>> hash(Base('b1'))
603887253
>>> hash(Extended('e1'))
Traceback (most recent call last):
File "", line 1, in
TypeError: unhashable type: 'Extended'
--
components: Interpreter Core
messages: 63258
nosy: jek
severity: normal
status: open
title: __eq__ / __hash__ check doesn't take inheritance into account
type: crash
versions: Python 2.6
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2235>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2234] cygwinccompiler.py fails for latest MinGW releases.
Jason Tishler <[EMAIL PROTECTED]> added the comment: If the version is guaranteed to be x.y or x.y.z, then the patch seems correct. Note I am not set up to test this patch and it has been years since I have looked at this part of the code base. Sorry, that I can't be more helpful. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2234> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2537] re.compile(r'((x|y+)*)*') should fail
New submission from Jason Orendorff <[EMAIL PROTECTED]>: Below, the second regexp seems just as guilty as the first to me. Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.compile(r'((x|y)*)*') Traceback (most recent call last): File "", line 1, in File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/re.py", line 180, in compile return _compile(pattern, flags) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/re.py", line 233, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat >>> re.compile(r'((x|y+)*)*') <_sre.SRE_Pattern object at 0x18548> I don't know if that error is to protect the sre engine from bad patterns or just a courtesy to users. If the former, it could be a serious bug. -- messages: 64865 nosy: jorendorff severity: normal status: open title: re.compile(r'((x|y+)*)*') should fail versions: Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2537> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2537] re.compile(r'((x|y+)*)*') should fail
Jason Orendorff <[EMAIL PROTECTED]> added the comment: Huh. Maybe you're right. JavaScript, Ruby, and Perl all accept both regexes, although no two agree on what should be captured: js> "xyyzy".replace(/((x|y)*)*/, "($1, $2)") (xyy, y)zy js> "xyyzy".replace(/((x|y+)*)*/, "($1, $2)") (xyy, yy)zy >> "xyyzy".sub(/((x|y)*)*/, "(\\1, \\2)") => "(, y)zy" >> "xyyzy".sub(/((x|y+)*)*/, "(\\1, \\2)") => "(, yy)zy" DB<1> $_ = 'xyyzy'; s/((x|y)*)*/(\1 \2)/; print ( )zy DB<2> $_ = 'xyyzy'; s/((x|y+)*)*/(\1 \2)/; print ( yy)zy Ruby's behavior seems best to me. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2537> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2641] setuptools gets site-packages wrong on Mac
New submission from Jason Orendorff <[EMAIL PROTECTED]>:
On my Mac, /usr/local/bin/python2.5 is a symlink to
"../../../Library/Frameworks/Python.framework/Versions/2.5/bin/python2.5".
When I install Mercurial from source, the "mercurial" package is
installed at "/usr/local/lib/python2.5/site-packages/mercurial", so the
installation is broken. Since "site-packages" appears nowhere in the
Mercurial source tree, I think it's setuptools (not Mercurial) that is
getting this wrong.
Mercurial's setup.py can be seen here:
(as of this writing)
http://hg.intevation.org/mercurial/crew/file/628da4a91628/setup.py
(the latest)
http://hg.intevation.org/mercurial/crew/file/tip/setup.py
I'm not sure what the Right Thing would be, but if it's agreed that the
current behavior is a hack, then `(p for p in sys.path if
p.endswith('site-packages')).next()`, falling back to the current
behavior, seems like a better hack.
Happy to patch, if someone can advise me; MvL?
--
components: Distutils
messages: 65527
nosy: jorendorff
severity: normal
status: open
title: setuptools gets site-packages wrong on Mac
versions: Python 2.4, Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2641>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4827] optparse: Callback example 1 is confusing
New submission from Jason Kankiewicz :
"Callback example 1: trivial callback" reads
Here’s an example of a callback option that takes no arguments, and
simply records that the option was seen:
def record_foo_seen(option, opt_str, value, parser):
parser.saw_foo = True
parser.add_option("--foo", action="callback",
callback=record_foo_seen)
but the following paragraph
Of course, you could do that with the store_true action.
is wrong because
parser.add_option("--foo", action="store_true", dest="saw_foo")
would actually be duplicated by
def record_foo_seen(option, opt_str, value, parser):
parser.values.saw_foo = True
parser.add_option("--foo", action="callback",
callback=record_foo_seen)
For example:
>>> from optparse import OptionParser
>>> parser = OptionParser()
>>> def record_foo_seen(option, opt_str, value, parser):
... parser.saw_foo = True
...
>>> parser.add_option("--foo", action="callback", callback=record_foo_seen)
>>> parser.parse_args(['--foo'])
(, [])
>>> parser = OptionParser()
>>> parser.add_option("--foo", action="store_true", dest="saw_foo")
>>> parser.parse_args(['--foo'])
(, [])
>>> parser = OptionParser()
>>> def record_foo_seen(option, opt_str, value, parser):
... parser.values.saw_foo = True
...
>>> parser.add_option("--foo", action="callback", callback=record_foo_seen)
>>> parser.parse_args(['--foo'])
(, [])
--
assignee: georg.brandl
components: Documentation
messages: 79039
nosy: georg.brandl, jkankiewicz
severity: normal
status: open
title: optparse: Callback example 1 is confusing
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
___
Python tracker
<http://bugs.python.org/issue4827>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2233] Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail
Jason Tishler added the comment: Sorry for the delay, but I was on vacation and then recovering from vacation... You are correct that my initial patch does not handle the case when DESTDIR is not specified. Your suggestion will work, but seems hacky. What about adding the defaulting of DESTDIR to "/" to my initial patch? This seems cleaner. See my second patch for the details. If this approach is acceptable, then feel free to move the defaulting of DESTDIR to a more appropriate place in Makefile.pre.in. I wasn't sure where to put this change. Added file: http://bugs.python.org/file12652/Makefile.pre.in.diff ___ Python tracker <http://bugs.python.org/issue2233> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2233] Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail
Jason Tishler added the comment: Obviously not... :,( It seems like we might have to go with your "/./" workaround, but let me see if I can come up with another approach. ___ Python tracker <http://bugs.python.org/issue2233> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2233] Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail
Jason Tishler added the comment: Your latest patch is on the right track, but see my latest one, Makefile.pre.in.v2.diff, for an optimization. I tested make install with and without DESTDIR defined on the command line and both cases behaved as expected. Added file: http://bugs.python.org/file12741/Makefile.pre.in.v2.diff ___ Python tracker <http://bugs.python.org/issue2233> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2233] Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail
Jason Tishler added the comment:
I guess you mean the following:
${var:-value}
Old BSD shells, including the Ultrix sh, don't accept the colon for
any shell substitution, and complain and die.
If so, should we just go forward without the colon? The bash manpage
indicates the following:
In each of the cases below, ... bash tests for a parameter that is
unset or null; omitting the colon results in a test only for a
parameter that is unset.
So, if a user executes "make DESTDIR= install", then the build will
fail. Or, maybe we shouldn't worry about that corner case.
What do you think?
___
Python tracker
<http://bugs.python.org/issue2233>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33523] loop.run_until_complete re-entrancy to support more complicated codebases in transition to asyncio
Jason Fried added the comment: Yeah I have to agree at this point, from a naive point of view it looks awesome, but its just as bad as loosing gil guarantees. On Mon, Aug 26, 2019 at 03:04 Andrew Svetlov wrote: > > Andrew Svetlov added the comment: > > The solution produces subtle and error-prone code. It can live in third > party library but not good enough for stdlib I think. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue33523> > ___ > -- ___ Python tracker <https://bugs.python.org/issue33523> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38218] SyntaxError in Tutorial 8.6 Defining Clean-up Actions
New submission from Jason Plurad : The second code example in Tutorial section 8.6 defines the function: def bool_return(): -> bool: which throws a SyntaxError: invalid syntax If the function wants to use a return annotation, there should not be a colon after the function name. I have a pull request ready for this. -- assignee: docs@python components: Documentation messages: 352746 nosy: Jason Plurad, docs@python priority: normal severity: normal status: open title: SyntaxError in Tutorial 8.6 Defining Clean-up Actions ___ Python tracker <https://bugs.python.org/issue38218> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38415] @asynccontextmanager decorated functions are not callable like @contextmanager
New submission from Jason Fried : The standard contextmanager decorator produces a wrapper that itself can be used as a decorator ``` @contextmanager def some_context(): ... yield @some_context() def some_function(): # we are inside a with some_context() now. ... ``` When I created a version of asynccontextmanager internally before it was available in the stdLib I copied this behavior and I have people internally to facebook using this behavior, Was there a reason this behavior was not replicated to asynccontextmanager? I have a diff an tests to add -- components: Library (Lib) messages: 354232 nosy: fried, yselivanov priority: normal severity: normal status: open title: @asynccontextmanager decorated functions are not callable like @contextmanager type: enhancement versions: Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38415] @asynccontextmanager decorated functions are not callable like @contextmanager
Change by Jason Fried : -- keywords: +patch pull_requests: +16250 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16667 ___ Python tracker <https://bugs.python.org/issue38415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38690] Command line option with &/or without a space results in the same outcome
New submission from jason gors :
The syntax in the Command line documentation was unexpected regarding the `-m`
option (specifically `python -mtimeit`) [0]. Showing this:
```
python -mtimeit "range(100)"
# behaving equivalent to this:
python -m timeit "range(100)"
```
This led me to discover many cases where command line arguments are like this
in python (e.g. the call working correctly without a space between an argument
flag and what is being passed into the command). Like this:
```
python -c"print('Hi')"
# behaving the same as:
python -c "print('Hi')"
```
This is also the case with pip as well:
```
pip install -rrequirements.txt
# behaving exactly like:
pip install -r requirements.txt
```
However, when I think of the *nix commands, like `rm`, this behavior fails.
When you want to pass several flags at once, you can either list them
separately (e.g. `rm -f -i myfile.py`) or concatenate them together (e.g. `rm
-fi myfile.py`), but `rm` fails if you try calling it without a space between
the argument(s) and the file to be removed (e.g.`rm -fimyfile.py`).
I'm not sure whether this command line behavior in python is intentional, but
it's not obvious as to why this is the case.
[0] https://docs.python.org/3/using/cmdline.html#cmdoption-m
--
components: Library (Lib)
messages: 355985
nosy: jgors
priority: normal
severity: normal
status: open
title: Command line option with &/or without a space results in the same outcome
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue38690>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44510] file.read() UnicodeDecodeError with large files on Windows
Change by Jason Yundt : -- nosy: +jayman ___ Python tracker <https://bugs.python.org/issue44510> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45175] No warning with '-W always' and cached import
New submission from Jason Yundt : I have a script which always produces a warning when you run it. If I import always_warns from another script, that script will only produce a warning once. Steps to reproduce: $ python -W always always_warns.py /tmp/Bug reproduction/always_warns.py:1: DeprecationWarning: invalid escape sequence \ "\ " $ python -W always always_warns.py /tmp/Bug reproduction/always_warns.py:1: DeprecationWarning: invalid escape sequence \ "\ " $ python -W always imports_always_warns.py /tmp/Bug reproduction/always_warns.py:1: DeprecationWarning: invalid escape sequence \ "\ " $ python -W always imports_always_warns.py $ There should be a warning for that last one, but there isn’t. If I delete __pycache__, imports_always_warns.py makes the warning appear again. -- files: Bug reproduction.zip messages: 401648 nosy: jayman priority: normal severity: normal status: open title: No warning with '-W always' and cached import type: behavior versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 Added file: https://bugs.python.org/file50278/Bug reproduction.zip ___ Python tracker <https://bugs.python.org/issue45175> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
