[issue36054] Way to detect CPU count inside docker container
Mike added the comment:
Is this issue still being worked on as a core feature? I needed a solution for
this using 2.7.11 to enable some old code to work properly/nicely in a
container environment on AWS Batch and was forced to figure out what OpenJDK
was doing and came up with a solution. The process in OpenJDK seems to be, find
where the cgroups for docker are located in the file system, then depending on
the values in different files you can determine the number of CPUs available.
The inelegant code below is what worked for me:
def query_cpu():
if os.path.isfile('/sys/fs/cgroup/cpu/cpu.cfs_quota_us'):
cpu_quota =
int(open('/sys/fs/cgroup/cpu/cpu.cfs_quota_us').read().rstrip())
#print(cpu_quota) # Not useful for AWS Batch based jobs as
result is -1, but works on local linux systems
if cpu_quota != -1 and
os.path.isfile('/sys/fs/cgroup/cpu/cpu.cfs_period_us'):
cpu_period =
int(open('/sys/fs/cgroup/cpu/cpu.cfs_period_us').read().rstrip())
#print(cpu_period)
avail_cpu = int(cpu_quota / cpu_period) # Divide quota by
period and you should get num of allotted CPU to the container, rounded down if
fractional.
elif os.path.isfile('/sys/fs/cgroup/cpu/cpu.shares'):
cpu_shares =
int(open('/sys/fs/cgroup/cpu/cpu.shares').read().rstrip())
#print(cpu_shares) # For AWS, gives correct value * 1024.
avail_cpu = int(cpu_shares / 1024)
return avail_cpu
This solution makes several assumptions about the cgroup locations within the
container vs dynamically finding where those files are located as OpenJDK does.
I also haven't included the more robust method in case cpu.quota and cpu.shares
are -1.
Hopefully this is a start for getting this implemented.
--
nosy: +mcnelsonphd
___
Python tracker
<https://bugs.python.org/issue36054>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38812] Comparing datetime.time objects incorrect for TZ aware and unaware
New submission from Mike :
import pytz
import datetime
tzaware_time1 = datetime.time(7,30,tzinfo=pytz.timezone("America/Denver"))
tzaware_time2 = datetime.time(7,30,tzinfo=pytz.utc)
tzunaware_time = datetime.time(7, 30)
# This fails with exception: TypeError: can't compare offset-naive and
offset-aware times
# even though both ARE tz aware.
tzaware_time1 < tzaware_time2
# This does NOT raise an exception and should since one is aware and one isn't.
tzunaware_time < tzaware_time1
--
messages: 356673
nosy: epicadv
priority: normal
severity: normal
status: open
title: Comparing datetime.time objects incorrect for TZ aware and unaware
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue38812>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38812] Comparing datetime.time objects incorrect for TZ aware and unaware
Mike added the comment: Ok. I'll file a bug on pytz. Thanks! On Sat, Nov 16, 2019 at 11:18 PM Karthikeyan Singaravelan < rep...@bugs.python.org> wrote: > > Change by Karthikeyan Singaravelan : > > > -- > nosy: +p-ganssle > > ___ > Python tracker > <https://bugs.python.org/issue38812> > ___ > -- ___ Python tracker <https://bugs.python.org/issue38812> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40581] scipy's differential_evolution bug
New submission from Mike : I have a random bug with scipy's optimize . I use it in the context of SageMath (Python 3.7.3). I checked 3 algorithms : shgo, dual_annealing and full_optimize. All don't work well (at all !). I optimise with a 3 parameters functions with given bounds. The algorithm randomly sends to my error function the "1e-8" value for any of the 3 parameters. I displayed the vector + error to understand it. AS you can see, in this case, the first parameter is 1e-8 whereas it is outside the bounds. Sometimes it happens for the second parameter, or the 3rd -- [3.95049282e-19 3.03055607e-20 1.96212098e+29] 0.0030238733573031864 [3.95273920e-19 3.05821352e-20 1.90997635e+29] 0.002957956545311753 [3.95037412e-19 3.04080173e-20 1.93312145e+29] 0.0029572689364709224 sage.all_cmdline:33: IntegrationWarning: The occurrence of roundoff error is detected, which prevents the requested tolerance from being achieved. The error may be underestimated. [1.e-08 3.04080173e-20 1.93312145e+29] 1.0713560755245306 Overflow [3.95037412e-19 3.04080173e-20 1.93312145e+29] 0.0029572689364709224 - The behaviour is the same for all of them. However the value inserted is not always the same, I noticed 3 : 1e-10, 1e-8 and 1.49011612e-08 Moreover, all do not send nice values. For example, the full_optimize always send values close to the highest bound. Perhaps are the value computed with a simple linear average and I guess it should not be the case. my bounds are : bounds = [(1*e,4*e),(0.1*e,0.5*e),(1e5,1e40)] with e=1.6e-19 Is there an alternative for optimization in python ? regards, Mike -- messages: 368540 nosy: mmyara priority: normal severity: normal status: open title: scipy's differential_evolution bug versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue40581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40581] scipy's differential_evolution bug
Mike added the comment: ok thank you Christian. I will do. > Le 9 mai 2020 à 23:06, Christian Heimes a écrit : > > > Christian Heimes added the comment: > > SciPy and Sage are 3rd party extensions to CPython and not maintained by us. > Please report the issue with SciPi, > https://www.scipy.org/scipylib/bug-report.html > > -- > nosy: +christian.heimes > resolution: -> third party > stage: -> resolved > status: open -> closed > > ___ > Python tracker > <https://bugs.python.org/issue40581> > ___ -- ___ Python tracker <https://bugs.python.org/issue40581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9631] Python 2.7 installation issue for Linux gcc-4.1.0-3 (Fedora Core 5?)
mike added the comment: Hi, I downloaded source and did the following instructions. We use Red Hat Enterprise Linux Server release 5.5. ./configure --prefix=/home/mike/python_rh_32 make make install I also changed the line in site.py from: s = os.path.join(os.path.dirname(sys.path.pop()), s) to: s = os.path.join(os.path.dirname(sys.path[-1]), s) but I still get: /usr/bin/install -c -m 644 ./LICENSE /home/mike/python_rh_32/lib/python2.7/LICENSE.txt PYTHONPATH=/home/mike/python_rh_32/lib/python2.7 \ ./python -Wi -tt /home/mike/python_rh_32/lib/python2.7/compileall.py \ -d /home/mike/python_rh_32/lib/python2.7 -f \ -x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \ /home/mike/python_rh_32/lib/python2.7 Traceback (most recent call last): File "/home/mike/python_rh_32/lib/python2.7/compileall.py", line 16, in import struct File "/home/mike/python_rh_32/lib/python2.7/struct.py", line 1, in from _struct import * ImportError: No module named _struct make: *** [libinstall] Error 1 Did anyone slove this problem? -- nosy: +eraonel ___ Python tracker <http://bugs.python.org/issue9631> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30160] BaseHTTPRequestHandler.wfile: supported usage unclear
New submission from Mike: The documentation for BaseHTTPRequestHandler explicitly prohibits protocol violations when writing to the `wfile` stream: > BaseHTTPRequestHandler has the following instance variables: > > [...] > > **`wfile`** > > > Contains the output stream for writing a response back to the client. > > Proper adherence to the HTTP protocol must be used when writing to this > > stream. I am interested in testing web browser behavior in response to protocol violations, and my initial interpretation of this text (and the term "must" in particular) is that such conditions are not guaranteed to achievable with this module. However, my colleague believes the text is simply intended to communicate that there is no safety mechanism in place, and that protocol violations will not be corrected. [1] Local testing and a quick reading of the source tends to confirm the latter interpretation, but this may simply be coincidental and not necessarily stable behavior. If it is in fact stable, then I would like to request a modification to the documentation. Changing the word "must" to "should" would help, although it might be better to be more explicit--something like, "Bytes are transmitted 'as-is'; HTTP protocol violations will not be corrected." Thanks! [1] https://github.com/w3c/web-platform-tests/issues/5668 -- assignee: docs@python components: Documentation messages: 292263 nosy: docs@python, jugglinmike priority: normal severity: normal status: open title: BaseHTTPRequestHandler.wfile: supported usage unclear ___ Python tracker <http://bugs.python.org/issue30160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30160] BaseHTTPRequestHandler.wfile: supported usage unclear
Mike added the comment: That would certainly satisfy me! -- ___ Python tracker <http://bugs.python.org/issue30160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30160] BaseHTTPRequestHandler.wfile: supported usage unclear
Changes by Mike : -- pull_requests: +1407 ___ Python tracker <http://bugs.python.org/issue30160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30160] BaseHTTPRequestHandler.wfile: supported usage unclear
Mike added the comment: My CLA signature has been verified, but based on the most recent comments, I'm not sure if something needs to change in this patch. Is there anything I can doto help this land? -- ___ Python tracker <http://bugs.python.org/issue30160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30160] BaseHTTPRequestHandler.wfile: supported usage unclear
Mike added the comment: It's been about a month since I heard back, so I thought I'd comment here just in case this slipped of anyone's radar. Is there anything I can doto help this land? -- ___ Python tracker <http://bugs.python.org/issue30160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30160] BaseHTTPRequestHandler.wfile: supported usage unclear
Mike added the comment: My pleasure. And thank you for backporting on my behalf :) -- ___ Python tracker <http://bugs.python.org/issue30160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18428] IDLE startup error
New submission from Mike: Python used to run smoothly on my macbook, but since I opened the debugger yesterday, the IDLE window cannot be opened anymore. It shows an error message "IDLE's subprocess didn't make connection". I tried to uninstall everything and download it again from the website, but the problem is unsolved. I am using the latest OS X Mountain Lion, and installed Python 3.3.2 and the latest Tcl/Tk. Please advice me how to fix the problem. -- components: IDLE messages: 192868 nosy: mwei11 priority: normal severity: normal status: open title: IDLE startup error type: crash versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue18428> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18428] IDLE startup error
Mike added the comment: Thanks Ned, I have solved the issue by deleting all my previous py files on my computer. But I couldn't figure out what really triggered this error, as those files did not create any problems before. -- ___ Python tracker <http://bugs.python.org/issue18428> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6399] Error reporting by logging.config.fileConfig()
Mike added the comment: Sorry, I only started learning Python a couple of weeks ago. Didn't know that there was a ConfigParser module. So this would really be a feature request of ConfigParser? Interesting you should mention Postel's Law. Being liberal about what you accept from others doesn't mean ignoring non-conformance. Jon Postel was clear that although you endeavour to continue when encountering non-conformance you should always report it, lest non-conformance propogates (sic). I can think of two ways ConfigParser could report these problems. Either you give it a callback function it can call as it encounters problems, or, after you have parsed a file you can call another function that gives a list of any problems encountered. If ConfigParser had this functionality it would then be straightforward for the logging.config.fileConfig module to send these warnings to the root logger. -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue6399> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6399] Error reporting by logging.config.fileConfig()
Mike added the comment: Hi Vinay, I will bow to your greater expertise on this and will let this go. It looks like it will be far more easier and robust just to invent my own logging config file format and read it myself. Thanks for your help. Mike. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue6399> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7121] ImportError of urllib.request & http.client under PYTHONHOME/Lib
New submission from mike :
There's a python program in the attached file http.py, I import
urllib.request in http.py, and urllib.request imports http.client.
When I try to run http.py by command "python http.py", the error is as
below:
Traceback (most recent call last):
File "http.py", line 4, in
import urllib.request
File "C:\Program Files\Python311\lib\urllib\request.py", line 86, in
import http.client
File "D:\program\python\http.py", line 6, in
response = urllib.request.urlopen('http://python.org/')
AttributeError: 'module' object has no attribute 'request'
However, if I copy http.py to directory PYTHONHOME/Lib and run
command "python http.py" under directory PYTHONHOME/Lib, it works
successfully; if you move it to other directories and run the command,
the error will be returned.
Note: the source code of http.py is copied from python311.chm under
directory PYTHONHOME/Doc.
--
components: Library (Lib)
files: http.py
messages: 93965
nosy: mikezp59
severity: normal
status: open
title: ImportError of urllib.request & http.client under PYTHONHOME/Lib
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file15121/http.py
___
Python tracker
<http://bugs.python.org/issue7121>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6399] Error reporting by logging.config.fileConfig()
New submission from Mike : Hi, I had a logging.conf file with the following logger def in it: [logger_Builder] level=DEBUG handlers=consoleStderr qualname=Builder propogate=0 And I couldn't understand why all my log messages were coming out twice. It took me four hours :-\ to realise I had misspelt "propagate". Wouldn't it be better if spurious names raised parsing exceptions? Thanks, Mike. P.S. Another thing that might have helped me track this down a little quicker is if I could have printed the name of the logger that was the source of some output. %(name)s gives the logger that *received* the log message. If there was another format variable for the logger that was the source of a log message I would have seen one message from Builder and one message from root and it would have been more obvious what was going on. -- components: Extension Modules messages: 90007 nosy: mike severity: normal status: open title: Error reporting by logging.config.fileConfig() type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue6399> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6399] Error reporting by logging.config.fileConfig()
Mike added the comment: Fair point. Agree that this is a feature request. Perhaps something like: logging.config.fileConfig(path, strict=False) -- ___ Python tracker <http://bugs.python.org/issue6399> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29437] installation not listed for all users
New submission from Mike: When installing Python 3.6 using the official installer and selecting "install for all users" from an account with admin privileges, the installation completes successfully and it shows in the list of installed programs for that user. However, because it's installation key is written into HKEY_CURRENT_USER, it is listed as installed program only for the user that ran the installation. While Python still seems to run from another account, it is not listed as an installed program for the other user. In the "install for all users" case, it should be registered in HKEY_LOCAL_MACHINE, instead of HKEY_CURRENT_USER. -- components: Installation, Windows messages: 286880 nosy: mray, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: installation not listed for all users versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue29437> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26413] python 3.5.1 uses wrong registry in system-wide installation
New submission from Mike:
The installer for python 3.5.1 (observed with the x64-86 executable installer,
assumed to happen with all installers) allows users to install python either
just for themselves or do a system-wide installation (provided they have
sufficient privileges).
However, when selecting a system-wide installation, the uninstall information
is registered to a key under HKEY_CURRENT_USER.
The result of this is that any user can run python 3.5.1; however, the entry in
the "uninstall programs" list shows only for the original user that installed
it.
This is in contrast to previous versions of python (e.g. 3.4.4) where any user
could uninstall it (provided they have sufficient privileges). It is also in
contrast to pylauncher of the same version (i.e. 3.5.1) which properly
registers itself under HKEY_LOCAL_MACHINE when selected to be installed for all
users.
The key in question is at this path:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\{b8440650-9dbe-4b7d-8167-6e0e3dcdf5d0}
I believe it should be here:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\{b8440650-9dbe-4b7d-8167-6e0e3dcdf5d0}
--
components: Installation
messages: 260700
nosy: mray
priority: normal
severity: normal
status: open
title: python 3.5.1 uses wrong registry in system-wide installation
type: behavior
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue26413>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10483] http.server - what is executable on Windows
Change by mike mcleod : -- pull_requests: +28437 pull_request: https://github.com/python/cpython/pull/30216 ___ Python tracker <https://bugs.python.org/issue10483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1284670] Allow to restrict ModuleFinder to get "direct" dependencies
Change by mike mcleod : -- pull_requests: +28450 pull_request: https://github.com/python/cpython/pull/30228 ___ Python tracker <https://bugs.python.org/issue1284670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4849] instantiating and populating xml.dom.minidom.Element is cumbersome
mike mcleod added the comment: I would like to help with this issue. I'm new to this space hence I am not aware of what patch review means. -- nosy: +mikecmcleod ___ Python tracker <https://bugs.python.org/issue4849> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24364] Not all defects pass through email policy
mike mcleod added the comment: I would like to help with this issue. -- nosy: +mikecmcleod ___ Python tracker <https://bugs.python.org/issue24364> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46377] TimedRotatingFileHandler "midnight" misleading when interval > 1
New submission from Mike Schiessl : Using the TimedRotatingFileHandler along with "when='midnight'" and interval > 1, midnight is handled equally to "days" which is a little misleading. Expectation: setting when to 'midnight', the file is rotated every midnight (interval value should be ignored) Current behavior: If 'midnight' is given alongside with an interval greater than 1 (.e.g 5), the (internal) interval (24*60*60) is calculated with the given interval -> 24*60*60 * 5. In my case, this led to some unforeseeable and unexpected behavior. -- components: Library (Lib) messages: 410558 nosy: mschiess, vinay.sajip priority: normal severity: normal status: open title: TimedRotatingFileHandler "midnight" misleading when interval > 1 type: behavior versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46377> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46377] TimedRotatingFileHandler "midnight" misleading when interval > 1
Mike Schiessl added the comment: i've just checked PR and you're right, something with the PR went wrong. Anyway, midnight (at least from the wording) specifies the "atTime". (which should be midnight). Again, if there's (by mistake) an interval bigger than 1 set(which in my mind makes no sense along to be used with midnight) things are getting pretty intransparent. The midnight handler created a logfile dated with 2021-12-15 (last night). Took me some time to get this sorted. (I've discovered, that I've set 30 in a default value file). Agreed on the backward compatibility, but I would assume someone using "midnight" would not expect any other behavior than "daily at midnight" besides using the atTime to modify the rollover time. (my opinion) -- ___ Python tracker <https://bugs.python.org/issue46377> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46377] TimedRotatingFileHandler "midnight" misleading when interval > 1
Mike Schiessl added the comment: Yes, enforcing interval == 1 or interval == None (which pulls the TimedRotatingFileHandler class __init__ default value which is also 1) works perfectly with midnight. I do not see any urge on that topic - as I personally now know the issue :D - but I really feel this fix could save someones else's time someday ;) So going the "safe" way via deprecation cycle seems to be the right approach -- ___ Python tracker <https://bugs.python.org/issue46377> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10202] ftplib doesn't check close status after sending file
mike mcleod added the comment: Working.. should be able to create pull request soon. Note part of suggestions include using SIOCOUTQ, but this does not have an equivalent for windows. And as Murphy's law goes this is likely to be where the problem is! -- ___ Python tracker <https://bugs.python.org/issue10202> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10202] ftplib doesn't check close status after sending file
Change by mike mcleod : -- keywords: +patch pull_requests: +28934 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/30747 ___ Python tracker <https://bugs.python.org/issue10202> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10434] Document the rules for "public names"
mike mcleod added the comment: I would like to help on this issue. Is there anyone available to push a PR through? If I make the changes. -- nosy: +mikecmcleod ___ Python tracker <https://bugs.python.org/issue10434> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1521051] Allow passing DocTestRunner and DocTestCase in doctest
mike mcleod added the comment: I would like to help on this issue. -- nosy: +mikecmcleod ___ Python tracker <https://bugs.python.org/issue1521051> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32658] Metacharacter (\) documentation suggestion
mike mcleod added the comment: I would like to help with this issue. Is that acceptable? -- nosy: +mikecmcleod ___ Python tracker <https://bugs.python.org/issue32658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32442] file_open unc
Change by Mike Auty : -- title: Result of pathlib.Path.resolve() with UNC path is not very useful -> file_open unc ___ Python tracker <https://bugs.python.org/issue32442> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32442] Result of pathlib Path.resolve() with UNC path is not very useful
Mike Auty added the comment: Sorry for the spam, thought I was in a different text box. 5:( -- nosy: +ikelos title: file_open unc -> Result of pathlib Path.resolve() with UNC path is not very useful ___ Python tracker <https://bugs.python.org/issue32442> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46654] file_open doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes)
New submission from Mike Auty :
I've found open to have difficulty with a resolved pathlib path:
Example code of:
import pathlib
path = "Z:\\test.py"
with open(path) as fp:
print("Stock open: works")
data = fp.read()
with open(pathlib.Path(path).resolve().as_uri()) as fp:
print("Pathlib resolve open")
data = fp.read()
Results in:
Z:\> python test.py
Stock open: works
Traceback (most recent call last):
File "Z:\test.py", line 12, in
with open(pathlib.Path(path).resolve().as_uri()) as fp:
FileNotFoundError: [Errno 2] No such file or directory:
"file://machine/share/test.py"
Interestingly, I've found that open("file:machine/share/test.py") succeeds,
but this isn't what pathlib's resolve() produces. It appears as though
file_open only supports hosts that are local, but will open UNC paths on
windows with the additional slashes. This is quite confusing behaviour and
it's not clear why file://host/share/file won't work, but
file:host/share/file does.
I imagine this is a long time issue and a decision has already been reached on
why file_open doesn't support such URIs, but I couldn't find the answer
anywhere, just issue 32442 which was resolved without clarifying the
situation...
--
messages: 412602
nosy: ikelos
priority: normal
severity: normal
status: open
title: file_open doesn't handle UNC paths produced by pathlib's resolve() (but
can handle UNC paths with additional slashes)
___
Python tracker
<https://bugs.python.org/issue46654>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46654] file_open doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes)
Mike Auty added the comment: > Why are you adding `.as_uri()`? The API we provide accepts URIs, so whilst the example seems a little contrived, the code itself expects a URI and then calls open (making use of the ability to add open handlers). > Builtin open() calls C open(). As best I can tell the file handler is defined in urllib/request.py as file_open. This appears to do some preprocessing to remove the file scheme and (and explicitly throws an exception if there's a host that isn't localhost) before it gets to the C open(). I wondered why it didn't check if it was on windows and, if so, construct an appropriate path (since quadruple hash I don't think adheres to the URI RFC, but seems to open correctly)? -- ___ Python tracker <https://bugs.python.org/issue46654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46654] file_open doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes)
Mike Auty added the comment: My bad, sorry, I realized I was conflating open with urllib.request.urlopen. I believe the issue still exists though, sorry for the confusion. -- ___ Python tracker <https://bugs.python.org/issue46654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46654] file_open doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes)
Mike Auty added the comment:
Here's the revised code sample:
import pathlib
import urllib.request
path = "Z:\\test.py"
print(f"Stock open: {pathlib.Path(path).as_uri()}")
with urllib.request.urlopen(pathlib.Path(path).as_uri()) as fp:
data = fp.read()
print(f"Pathlib resolved open: {pathlib.Path(path).resolve().as_uri()}")
with urllib.request.urlopen(pathlib.Path(path).resolve().as_uri()) as fp:
data = fp.read()
and here's the output:
Z:\> python test.py
Stock open: file:///Z:/test.py
Pathlib resolved open: file://host/share/test.py
Traceback (most recent call last):
File "C:\Program Files\Python310\lib\urllib\request.py", line 1505, in
open_local_file
stats = os.stat(localfile)
FileNotFoundError: [WinError 2] The system cannot find the file specified:
'\\share\\test.py'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "Z:\test.py", line 14, in
with urllib.request.urlopen(pathlib.Path(path).resolve().as_uri()) as
fp:
File "C:\Program Files\Python310\lib\urllib\request.py", line 216, in
urlopen
return opener.open(url, data, timeout)
File "C:\Program Files\Python310\lib\urllib\request.py", line 519, in open
response = self._open(req, data)
File "C:\Program Files\Python310\lib\urllib\request.py", line 536, in _open
result = self._call_chain(self.handle_open, protocol, protocol +
File "C:\Program Files\Python310\lib\urllib\request.py", line 496, in
_call_chain
result = func(*args)
File "C:\Program Files\Python310\lib\urllib\request.py", line 1483, in
file_open
return self.open_local_file(req)
File "C:\Program Files\Python310\lib\urllib\request.py", line 1522, in
open_local_file
raise URLError(exp)
urllib.error.URLError:
--
___
Python tracker
<https://bugs.python.org/issue46654>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46654] file_open doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes)
Mike Auty added the comment: I can confirm that url2pathname work with either number of slashes, and that open_file appears to have had the file: removed. However, in even if the check in open_file were bypassed, it calls open_local_file, which then strips any host before calling url2pathname, meaning the host will never be included if only two slashes are used. host, file = _splithost(url) localname = url2pathname(file) This is what seems to cause the issue when attempting to open file://server/host/file.ext on windows, even though file:server/host/file.ext open just fine. The problem that I found, and was in bug #32442, is that pathlib only ever returns two slashes, which despite being a valid and correctly formed url, can't be opened by urllib.request.urlopen(). Since there doesn't seem to be an issue with opening these files (given it works for file:server...) and since nt2pathname will produce the correct result, it feels as though open_file should have special code on windows to allow servers to be accepted by the file handler (open_local_file should probably stay as is to not change the API too much). -- ___ Python tracker <https://bugs.python.org/issue46654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46654] urllib.request.urlopen doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes)
Change by Mike Auty : -- title: file_open doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes) -> urllib.request.urlopen doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes) ___ Python tracker <https://bugs.python.org/issue46654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43882] [security] CVE-2022-0391: urllib.parse should sanitize urls containing ASCII newline and tabs.
Mike Lissner added the comment: Looks like that CVE isn't public yet. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0391 Any chance I can get access (I originally reported this vuln.). My email is m...@free.law, if it's possible and my email is needed. Thanks! -- ___ Python tracker <https://bugs.python.org/issue43882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46751] Windows-style path is not recognized under cygwin
New submission from Mike Kaganski : Using cyqwin 3.3.4-2, and python3: Python 3.9.10 (main, Jan 20 2022, 21:37:52) [GCC 11.2.0] on cygwin Trying this bash command line: > python3 C:/path/to/script.py results in this error: "python3: can't open file '/cygdrive/c/path/to/curdir/C:/path/to/script.py': [Errno 2] No such file or directory" OTOH, calling it like > python3 /cygdrive/c/path/to/script.py gives the expected output: "usage: script.py [-h] ..." It seems that python3 doesn't recognize "C:/path/to/script.py" to be a proper full path under cygwin, while most other cygwin apps handle those fine. E.g., > nano C:/path/to/script.py opens the script for editing without problems. The mentioned path syntax is useful and supported under cygwin, so it would be nice if python3 could support it, too. Especially useful it is in mixed development environment, mixing Windows native tools and cygwin ones; using such path style allows to use same paths for both kinds of tools, simplifying scripts. -- components: Windows messages: 413247 nosy: mikekaganski, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows-style path is not recognized under cygwin type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue46751> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46751] Windows-style path is not recognized under cygwin
Mike Kaganski added the comment: Thanks for looking at this! > Are you running from bash (or another cygwin shell), or from cmd.exe, or > something else? :) Citing myself: > Trying this *bash* command line: > To my knowledge, cygwin's installer doesn't have a 3.9 available. It does: https://cygwin.com/packages/summary/python3.html -- ___ Python tracker <https://bugs.python.org/issue46751> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46751] Windows-style path is not recognized under cygwin
Mike Kaganski added the comment: > As for 3.9: it's not available through the 64 bit installer (at least, I > don't see it there). I'll look and see what's involved in installing it. I don't remember if I did something special to install it; however, just maybe you need to install python39 directly. > Are you running the 32- or 64-bit version? 64-bit. > Does Cygwin not use : as a path list separator? It uses : as path separator: $ echo $PATH /opt/lo/bin:/usr/local/bin:/usr/bin:/cygdrive/c/Program Files/AdoptOpenJDK/jdk-11.0.7.10-hotspot/bin:/cygdrive/c/Program Files (x86)/Common Files/Oracle/Java/javapath:/cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/Windows/System32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:... But obviously, it can't use Windows-style paths in the $PATH (for that reason?). -- ___ Python tracker <https://bugs.python.org/issue46751> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue852532] ^$ won't split on empty line
Mike Coleman added the comment: Well, I think we can conclude that it's expected by *them*. :-) I still find it surprising, and it somewhat lessens the utility of re.split for my use cases. (I think re.finditer may also suffer from the same problem, but I don't recall.) If you look at the comments attached to the patch for this bug, it looks like akuchling and rhettinger more or less saw this as being a bug worth fixing, though there were questions about exactly what the correct fix should be. http://bugs.python.org/issue988761 One comment about the your doc fix: You highlight a fairly useless zero-character match (e.g., "x*") to demonstrate the behavior, which might leave the user scratching his head. (I think this case was originally mentioned as a corner case, not one that would be useful.) It'd be nice to highlight a more useful case like '^(?=S)' or perhaps a little more generically something like '^(?=HEADER)' or '^(?=BEGIN)' which is a usage that tripped me up in the first place. Thanks for working on this! Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue852532> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1204] readline configuration for shared libs w/o curses dependencies
New submission from Mike Beachy:
For RHEL 3 (and it also appears RHEL 4 and 5) the libreadline shared lib
has no specified lib requirement that satisfies the tgetent and related
symbols. (These symbols are provided by ncursesw, ncurses, curses,
termcap as noted in the python setup.py.) The configure script does not
add these required libs in for the readline tests, and so the autoconf
tests will fail and it will incorrectly determine that readline is not
present (and so not define HAVE_RL_COMPLETION_MATCHES etc.)
I guess this generally does not prevent the readline module from being
compiled since setup.py does its own search for readline and adds in the
needed curses library. It does prevent proper declaration of the
completion_matches function, however. On 32 bit systems this doesn't
matter but on 64 bit ones it does as the undeclared (but present in
libreadline) completion_matches returns a char **.
The fix checked in with r54874 after the 2.5.1 release (issue 1703270)
to Modules/readline.c fixes the problem for completion_matches
specifically, but the problem of incorrect determination of readline
presence still exists.
Attached is a patch to fix the problem: it adds the necessary additional
library to the temporary LIBS definition in the readline tests, using
the same order of curses libs specified in setup.py. (The patch includes
the changes for the configure script in addition to configure.in.)
--
components: Installation
files: full.patch
messages: 56140
nosy: mbeachy
severity: normal
status: open
title: readline configuration for shared libs w/o curses dependencies
type: compile error
versions: Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1204>
__Index: configure
===
--- configure (revision 58227)
+++ configure (working copy)
@@ -1,5 +1,5 @@
#! /bin/sh
-# From configure.in Revision: 57904 .
+# From configure.in Revision: 57960 .
# Guess values for system-dependent variables and create Makefiles.
# Generated by GNU Autoconf 2.61 for python 2.6.
#
@@ -21500,6 +21500,93 @@
fi
+# This will find the lib that defines tgetent and add it to LIBS; it is
+# necessary for readline tests on platforms for which readline shared libs
+# don't have a dependency on curses libs.
+{ echo "$as_me:$LINENO: checking for library containing tgetent" >&5
+echo $ECHO_N "checking for library containing tgetent... $ECHO_C" >&6; }
+if test "${ac_cv_search_tgetent+set}" = set; then
+ echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+ ac_func_search_save_LIBS=$LIBS
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h. */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h. */
+
+/* Override any GCC internal prototype to avoid an error.
+ Use char because int might match the return type of a GCC
+ builtin and then its argument prototype would still apply. */
+#ifdef __cplusplus
+extern "C"
+#endif
+char tgetent ();
+int
+main ()
+{
+return tgetent ();
+ ;
+ return 0;
+}
+_ACEOF
+for ac_lib in '' ncursesw ncurses curses termcap; do
+ if test -z "$ac_lib"; then
+ac_res="none required"
+ else
+ac_res=-l$ac_lib
+LIBS="-l$ac_lib $ac_func_search_save_LIBS"
+ fi
+ rm -f conftest.$ac_objext conftest$ac_exeext
+if { (ac_try="$ac_link"
+case "(($ac_try" in
+ *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
+ *) ac_try_echo=$ac_try;;
+esac
+eval "echo \"\$as_me:$LINENO: $ac_try_echo\"") >&5
+ (eval "$ac_link") 2>conftest.er1
+ ac_status=$?
+ grep -v '^ *+' conftest.er1 >conftest.err
+ rm -f conftest.er1
+ cat conftest.err >&5
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); } && {
+ test -z "$ac_c_werror_flag" ||
+ test ! -s conftest.err
+ } && test -s conftest$ac_exeext &&
+ $as_test_x conftest$ac_exeext; then
+ ac_cv_search_tgetent=$ac_res
+else
+ echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+
+fi
+
+rm -f core conftest.err conftest.$ac_objext conftest_ipa8_conftest.oo \
+ conftest$ac_exeext
+ if test "${ac_cv_search_tgetent+set}" = set; then
+ break
+fi
+done
+if test "${ac_cv_search_tgetent+set}" = set; then
+ :
+else
+ ac_cv_search_tgetent=no
+fi
+rm conftest.$ac_ext
+LIBS=$ac_func_search_save_LIBS
+fi
+{ echo "$as_me:$LINENO: result: $ac_cv_search_tgetent" >&5
+echo "${ECHO_T}$ac_cv_search_tgetent" >&6; }
+ac_res=$ac_cv_search_tgetent
+if test "$ac_res" != no; then
+ test "$ac_res" = "none required" || LIBS=&quo
[issue1274] doctest fails to run file based tests with 8bit paths
New submission from Mike Taylor: In our builds the included patch fixes this issue. Patch by Brian Kirsch, tested at OSAF on Python 2.5.1 -- nosy: +bear __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1274> __ bug_3740_1.patch Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1274] doctest fails to run file based tests with 8bit paths
Changes by Mike Taylor: -- components: Tests severity: major status: open title: doctest fails to run file based tests with 8bit paths type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1274> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1663329] subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi
Mike Klaas added the comment: This problem has also afflicted us. Attached is a patch which adds closerange(fd_low, fd_high) to the posix (and consequently os) module, and modifies subprocess to use it. Patch is against trunk but should work for 2.5maint. I don't really think that this is useful enough to add to the public api, but it results in a huge performance benefit for subprocess: [python-trunk]$ ./python -m timeit -s 'import python_close' 'python_close.go(10)' 10 loops, best of 3: 358 msec per loop [python-trunk]$ ./python -m timeit -s 'import os' 'os.closerange(4, 10)' 10 loops, best of 3: 20.7 msec per loop [python-trunk]$ ./python -m timeit -s 'import python_close' 'python_close.go(30)' 10 loops, best of 3: 1.05 sec per loop [python-trunk]$ ./python -m timeit -s 'import os' 'os.closerange(4, 30)'10 loops, best of 3: 63 msec per loop [python-trunk]$ cat python_close.py import os, sys def go(N): for i in xrange(4, N): try: os.close(i) except: pass -- nosy: +klaas _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1663329> _ posix_closerange.patch Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1663329] subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi
Mike Klaas added the comment: I see that some spaces crept in to the patch. I can fix that (and perhaps rename the function to start with an underscore) if desired. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1663329> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1663329] subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi
Mike Klaas added the comment: Finally, I did not include any platform-specific optimizations, as I don't have AIX or solaris boxes on which to test them (and they can easily be added later). An order-mag speedup on all *nix platforms is a good start. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1663329> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1516330] Module uuid: functions for retrieving MAC addres
Mike Klaas added the comment: Is this meant to be inserted into uuid.py? It seems more like a snippet from unrelated code: code coventions do not follow PEP 8; there are no tests; code does not run as-is (references non-existent variable '_os'-- why no 'import os'?); etc. -- nosy: +klaas _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1516330> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1516327] Module uuid: reduce pickle footprint
Mike Klaas added the comment: Is the footprint of UUID an issue? Note that changing the pickle format of UUID will require code that can unpickle both versions, for compatibility. I don't really see the need. Also, no real patch provided. -- nosy: +klaas _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1516327> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1705170] contextmanager eats StopIteration
Mike Klaas added the comment:
Verified on 2.5.0. The problem stems from contextmanager.__exit__:
def __exit__(self, type, value, traceback):
if type is None:
try:
self.gen.next()
except StopIteration:
return
else:
raise RuntimeError("generator didn't stop")
else:
try:
self.gen.throw(type, value, traceback)
raise RuntimeError("generator didn't stop after throw
()")
except StopIteration, exc:
# Suppress the exception *unless* it's the same
exception that
# was passed to throw(). This prevents a StopIteration
# raised inside the "with" statement from being
suppressed
return exc is not value
except:
# only re-raise if it's *not* the exception that was
# passed to throw(), because __exit__() must not raise
# an exception unless __exit__() itself failed. But
throw()
# has to raise the exception to signal propagation, so
this
# fixes the impedance mismatch between the throw()
protocol
# and the __exit__() protocol.
#
if sys.exc_info()[1] is not value:
raise
Conjecture: internal StopIteration exceptions are always the same
instance (PyExc_StopIteration) when propagated to python, invalidating
the return exc is not value
check.
--
nosy: +klaas
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1705170>
_
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1773632] Remove references to _xmlrpclib from xmlrpclib.py
Mike Klaas added the comment: Patch applies to 2.5 cleanly, test_xmlrpc passes. -- nosy: +klaas _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1773632> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue738948] Logic Variable Thread Synchronization
Mike Klaas added the comment: PEPs should be proposed on python-list and python-dev. This is a four- year-old idea that seems quite profound in the changes proposed. Recommend closing. -- nosy: +klaas Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue738948> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue737648] Error on handling nan
Mike Verdone added the comment:
For the benefit of those who stumble here through Google, here's a
workaround I've discovered for NaN testing. This is BAD:
value == float('NaN')
But this seems to work ok:
str(value) == str(float('NaN'))
--
nosy: +mike.verdone
title: Error on handling nan -> Error on handling nan
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue737648>
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13075] PEP-0001 contains dead links
Mike Hoy added the comment: I'm working on making a patch for this. I just want to confirm that the information I found is correct: Article Name OLD URL ARCHIVED URL How Python is Developed OLD: http://www.python.org/dev/intro/ ARCHIVE: http://www.etsimo.uniovi.es/python/dev/intro/ Python's Development Process http://www.python.org/dev/process/ http://www.etsimo.uniovi.es/python/dev/process/ Why Develop Python? http://www.python.org/dev/why/ http://www.etsimo.uniovi.es/python/dev/why/ Development Tools http://www.python.org/dev/tools/ http://www.etsimo.uniovi.es/python/dev/tools/ Frequently Asked Questions for Developers http://www.python.org/dev/faq/ http://www.etsimo.uniovi.es/python/dev/faq/ -- nosy: +mikehoy ___ Python tracker <http://bugs.python.org/issue13075> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13075] PEP-0001 contains dead links
Mike Hoy added the comment: Of course I would be creating new articles based on the archived pages. -- ___ Python tracker <http://bugs.python.org/issue13075> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13075] PEP-0001 contains dead links
Mike Hoy added the comment: Added links under Resources to the new Dev Guide. Added a link to the Guide itself and a link to the faq. -- keywords: +patch Added file: http://bugs.python.org/file23289/pep-0001-broken-links.diff ___ Python tracker <http://bugs.python.org/issue13075> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12436] Missing items in installation/setup instructions
Mike Hoy added the comment: > - How to prepare a text editor See: http://docs.python.org/dev/using/unix.html#editors > - How to run Python code from a file (if the tutorial or using docs don’t > already have it). See: http://docs.python.org/dev/using/unix.html#miscellaneous -- nosy: +mikehoy ___ Python tracker <http://bugs.python.org/issue12436> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12823] Broken link in "SSL wrapper for socket objects" document
Mike Hoy added the comment: Patch to remove broken link. -- keywords: +patch nosy: +mikehoy Added file: http://bugs.python.org/file23334/SSL-broken-link.diff ___ Python tracker <http://bugs.python.org/issue12823> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12192] Doc that collection mutation methods return item or None
Changes by Mike Hoy : -- nosy: +mikehoy ___ Python tracker <http://bugs.python.org/issue12192> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12602] Missing using docs cross-references
Changes by Mike Hoy : -- nosy: +mikehoy ___ Python tracker <http://bugs.python.org/issue12602> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12436] Missing items in installation/setup instructions
Mike Hoy added the comment: > Thanks Mike! So the first item is covered (at least for UNIX, can you > check the Windows docs too?), but not the second. http://docs.python.org/dev/using/windows.html Makes no reference to preparing a text editor. This I could help with but... > The item you linked > to explains how to modify a script so that it’s possible to run > ./script on Unix, but does not give an actual example of running it, > nor does it explain “python script” or “python script.py” or “python -m > module”. Some one else would have to write this part unless you can give me some info about how it should be worded. -- ___ Python tracker <http://bugs.python.org/issue12436> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12436] Missing items in installation/setup instructions
Mike Hoy added the comment: > mostly to recommend Notepad++ I think. In addition to Notepad++ do you think it would be a good idea to at least mention Vim and Emacs with a disclaimer about the learning curve? > For Windows users, added a section about how to use a terminal and Do you think it would be a good idea to add instructions on how to add Python to the Path in Windows? It could be 'borrowed' from the Boston Python Workshop Page I would think. It's pretty long but useful considering how much trouble I have had having to do this myself under Windows. -- ___ Python tracker <http://bugs.python.org/issue12436> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3902] Packages containing only extension modules have to contain __init__.py
Mike Hoy added the comment: > We’re working on a patch on the core-mentorship list. Éric, I emailed the diff to the Core-Mentorship list, but since there was no reply I will just attach it here. Please review patch and let me know if you want any changes. -- keywords: +patch nosy: +mikehoy Added file: http://bugs.python.org/file23340/distutils-init.py-apiref-setup.diff ___ Python tracker <http://bugs.python.org/issue3902> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12192] Doc that collection mutation methods return item or None
Mike Hoy added the comment: Created a patch based on suggestions here. -- keywords: +patch Added file: http://bugs.python.org/file23346/return-none.diff ___ Python tracker <http://bugs.python.org/issue12192> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12436] Missing items in installation/setup instructions
Mike Hoy added the comment: Here is what I have so far: > For Windows users, added a section about how to use a terminal How to use a terminal Open a command prompt: * On Windows Vista or Windows 7: click on the Start menu (the Windows logo in the lower left of the screen), type cmd into the Search field directly above the Start menu button, and click on "cmd" in the search results above the Search field. * On Windows XP: click on the Start menu (the Windows logo in the lower left of the screen), click on "Run...", type cmd into the text box, and hit enter. Commands used in terminal * cd C:\ - Puts you in the root directory of the C drive. * cd Python32 - Puts you in the directory where Python 3.2 is installed. * dir - This command lists the contents of the Python32 directory. * python - This command will invoke python.exe and bring up the interpreter. > a link to PowerShell Windows PowerShell Windows PowerShell is a task-based command-line shell and scripting language designed for system administration. It can be obtained here: http://technet.microsoft.com/en-us/library/bb978526.aspx. -- ___ Python tracker <http://bugs.python.org/issue12436> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3902] Packages containing only extension modules have to contain __init__.py
Mike Hoy added the comment: Submitted v2 of my patch after reading Éric's review of my first. -- Added file: http://bugs.python.org/file23360/apiref-setupscript-v2.diff ___ Python tracker <http://bugs.python.org/issue3902> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12602] Missing cross-references in Doc/using
Changes by Mike Hoy : -- nosy: -mikehoy ___ Python tracker <http://bugs.python.org/issue12602> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3902] Packages containing only extension modules have to contain __init__.py
Mike Hoy added the comment: Responded to first question in apiref and uploaded a new patch that wraps lines at 80 characters. -- Added file: http://bugs.python.org/file23369/apiref-setupscript-v3.diff ___ Python tracker <http://bugs.python.org/issue3902> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3902] Packages containing only extension modules have to contain __init__.py
Mike Hoy added the comment: setupscript did not have the changes that were made in apiref. v4 is now consistent and line wrapping at 80 chars. -- Added file: http://bugs.python.org/file23384/apiref-setupscript-v4.diff ___ Python tracker <http://bugs.python.org/issue3902> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13154] pep-0000.txt doesn't build anymore
Changes by Mike Hoy : -- nosy: +mikehoy ___ Python tracker <http://bugs.python.org/issue13154> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13154] pep-0000.txt doesn't build anymore
Mike Hoy added the comment:
:~/peps$ find . -name "*.txt" | xargs grep "canterbury"
./pep-3152.txt:Author: Gregory Ewing
./pep-0380.txt:Author: Gregory Ewing
./pep-0284.txt:Greg Ewing
./pep-0335.txt:Author: Gregory Ewing
Looks like pep-0335.txt has a "Gregory Ewing" with a different email address
(g...@cosc.canterbury.ac.nz) that is normally associated with "Gregory Ewing"
(greg.ew...@canterbury.ac.nz).
Which is an error according to:
pep0/output.py:
if too_many_emails:
err_output = []
for author, emails in too_many_emails:
err_output.append("%s: %r" % (author, emails))
raise ValueError("some authors have more than one email address "
"listed:\n" + '\n'.join(err_output))
--
___
Python tracker
<http://bugs.python.org/issue13154>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13191] Typo in argparse documentation
New submission from Mike Hoy : In the Docs mailing list a typo was pointed out in argparse docs. http://docs.python.org/dev/library/argparse.html#metavar > "So, a single positional argument with dest='bar' will that argument > will be referred to as bar." > "So, a single positional argument with dest='bar' WITH that argument > will be referred to as bar." Eli Bendersky: > I agree the original sentence makes little sense. But I'm not sure > your correction fully fixes it either - "a single positional argument > ... with that argument" doesn't sound right. > Perhaps it should just say: > "So, a single positional argument with dest='bar' will be referred to > as > bar" ? Patch says "So,a single positional argument with dest='bar' will be referred to as bar" -- assignee: docs@python components: Documentation files: typo-argparse.diff keywords: patch messages: 145636 nosy: docs@python, mikehoy priority: normal severity: normal status: open title: Typo in argparse documentation Added file: http://bugs.python.org/file23420/typo-argparse.diff ___ Python tracker <http://bugs.python.org/issue13191> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11776] types.MethodType() params and usage is not documented
Changes by Mike Hoy : -- nosy: +mikehoy ___ Python tracker <http://bugs.python.org/issue11776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11638] pysetup un sdist crashes with weird trace if version is unicode by accident
Changes by Mike Hoy : -- nosy: +mikehoy ___ Python tracker <http://bugs.python.org/issue11638> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12944] Accept arbitrary files for packaging's upload command
Changes by Mike Hoy : -- nosy: +mikehoy ___ Python tracker <http://bugs.python.org/issue12944> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13198] Remove duplicate definition of write_record_file
Changes by Mike Hoy : -- nosy: +mikehoy ___ Python tracker <http://bugs.python.org/issue13198> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13341] Incorrect documentation for "u" PyArg_Parse format unit
Changes by Mike Hoy : -- nosy: +mikehoy ___ Python tracker <http://bugs.python.org/issue13341> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13459] logger.propagate=True behavior clarification
New submission from Mike Fogel : Hi, there's been a fair amount of confusion over the interaction between logger.propagate and the ancestor logger's handlers and level. http://bugs.python.org/issue7535 http://bugs.python.org/issue8327 http://bugs.python.org/issue9606 I think most this confusion could be avoided if the documentation for logger.propagate were expanded to explain clearly what happens when propagate evaluates to True - right now it just explains clearly what happens when it evaluates to False. Attached is a documentation patch that does this. Thanks for your consideration! -- assignee: docs@python components: Documentation files: logger_propagate_doc.diff keywords: patch messages: 148164 nosy: docs@python, mfogel, vinay.sajip priority: normal severity: normal status: open title: logger.propagate=True behavior clarification versions: Python 2.7, Python 3.3 Added file: http://bugs.python.org/file23761/logger_propagate_doc.diff ___ Python tracker <http://bugs.python.org/issue13459> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13531] add test for defaultdict with non-callable first argument
New submission from mike c :
Could a test be added to ./Lib/test/test_defaultdict.py to test for TypeError
being thrown when the the first argument to collections.defaultdict is not
callable?
pypy does not behave the same way as CPython 2.7.2 as the problem is not
covered in the testcases.
e.g.
def test_callable_arg:
d1 = defaultdict({})
self.assertRaises(TypeError) # TypeError: first argument must be callable
--
components: Tests
messages: 148868
nosy: mike.c
priority: normal
severity: normal
status: open
title: add test for defaultdict with non-callable first argument
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue13531>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13531] add test for defaultdict with non-callable first argument
mike c added the comment: Cloning repo. Reading the devguide. Patch forthcoming. -- ___ Python tracker <http://bugs.python.org/issue13531> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13531] add test for defaultdict with non-callable first argument
mike c added the comment: Patch to add a defaultdict test which checks that if the first argument is not callable, then a TypeError is thrown. -- keywords: +patch Added file: http://bugs.python.org/file23855/defaultdict_callable_test.patch ___ Python tracker <http://bugs.python.org/issue13531> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13531] add test for defaultdict with non-callable first argument
mike c added the comment: patch v2. Now with assertRaises()! -- Added file: http://bugs.python.org/file23856/defaultdict_callable_test_v2.patch ___ Python tracker <http://bugs.python.org/issue13531> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12190] intern filenames in bytecode
New submission from Mike Solomon : I work on a large app and we noticed that a surprising portion of our heap was filenames embedded the the bytecode. This one-line patch to intern filenames reduces our on-disk size about ~15% and brings down our heap and in-memory object count by a similar percentage. -- components: Interpreter Core files: codegen.patch keywords: patch messages: 136997 nosy: Mike.Solomon priority: normal severity: normal status: open title: intern filenames in bytecode type: performance versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file22131/codegen.patch ___ Python tracker <http://bugs.python.org/issue12190> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12190] intern filenames in bytecode
Mike Solomon added the comment: If you have a file with say a hundred functions, and each function contains the full path of that file on disk, your pyc file will contain about (100*(path_size+overhead)) bytes. In some cases, this is pretty significant. On Thu, May 26, 2011 at 12:47 PM, Benjamin Peterson wrote: > > Benjamin Peterson added the comment: > > How exactly does it bring down your disk space? > > -- > nosy: +benjamin.peterson > > ___ > Python tracker > <http://bugs.python.org/issue12190> > ___ > -- Added file: http://bugs.python.org/file22136/unnamed ___ Python tracker <http://bugs.python.org/issue12190> ___If you have a file with say a hundred functions, and each function contains the full path of that file on disk, your pyc file will contain about (100*(path_size+overhead)) bytes. In some cases, this is pretty significant. On Thu, May 26, 2011 at 12:47 PM, Benjamin Peterson <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> wrote: Benjamin Peterson <mailto:benja...@python.org";>benja...@python.org> added the comment: How exactly does it bring down your disk space? -- nosy: +benjamin.peterson ___ Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> <http://bugs.python.org/issue12190"; target="_blank">http://bugs.python.org/issue12190> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12190] intern filenames in bytecode
Mike Solomon added the comment: The in-memory fix is really the most important - the disk space was a bonus and an easy metric to gather. Unfortunately, our app won't be upgrading to python 3.x. On Fri, May 27, 2011 at 7:10 AM, Benjamin Peterson wrote: > > Benjamin Peterson added the comment: > > As you can see, I've implemented a similar solution in 3.3. It should have > the same memory savings but not disk space saving. (This would require > reintroducing the marshal feature for interned strings.) > > -- > > ___ > Python tracker > <http://bugs.python.org/issue12190> > ___ > -- Added file: http://bugs.python.org/file22159/unnamed ___ Python tracker <http://bugs.python.org/issue12190> ___The in-memory fix is really the most important - the disk space was a bonus and an easy metric to gather. Unfortunately, our app won't be upgrading to python 3.x.On Fri, May 27, 2011 at 7:10 AM, Benjamin Peterson <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> wrote: Benjamin Peterson <mailto:benja...@python.org";>benja...@python.org> added the comment: As you can see, I've implemented a similar solution in 3.3. It should have the same memory savings but not disk space saving. (This would require reintroducing the marshal feature for interned strings.) -- ___ Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> <http://bugs.python.org/issue12190"; target="_blank">http://bugs.python.org/issue12190> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7511] msvc9compiler.py: ValueError: [u'path']
mike bayer added the comment: regarding "hey this is an MS bug not Python", projects which feature optional C extensions are starting to apply workarounds for the issue on their end (I will need to commit a specific catch for this to SQLAlchemy) - users need to install our software and we need to detect compilation failures as a sign to move on without it. I think it's preferable for Python distutils to work around an MS issue rather than N projects having to work around an MS issue exposed through distutils. Seems like this bug has been out there a real long time...bump ? -- nosy: +zzzeek ___ Python tracker <http://bugs.python.org/issue7511> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7511] msvc9compiler.py: ValueError: [u'path']
mike bayer added the comment: > I think it's fair to ask the user to setup the environment correctly before running "python setup.py install" We're supporting automatic fallback to non-C install for those environments that don't support it. We're just looking for a predictable CCompilerError to be raised for conditions like this rather than a ValueError where we have to parse the string message. -- ___ Python tracker <http://bugs.python.org/issue7511> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12717] ConfigParser._Chainmap error in 2.7.2
New submission from Mike Garabedian : Issue 11089 submitted a patch to 3.2 and 2.7 to address performance concerns with the latest updates to ConfigParser. In the implementation for 2.7.2, this patch was misapplied in the keys() function on line 573: for mapping in self_maps: should be: for mapping in self._maps: As a result the following raises a NameError: >>> import ConfigParser >>> ConfigParser._Chainmap() Traceback (most recent call last): File "", line 1, in File "C:\Python27\lib\UserDict.py", line 172, in __repr__ return repr(dict(self.iteritems())) File "C:\Python27\lib\UserDict.py", line 110, in iteritems for k in self: File "C:\Python27\lib\UserDict.py", line 97, in __iter__ for k in self.keys(): File "C:\Python27\lib\ConfigParser.py", line 573, in keys for mapping in self_maps: NameError: global name 'self_maps' is not defined -- components: Extension Modules messages: 141823 nosy: georg.brandl, lukasz.langa, mgarabed, rhettinger, skip.montanaro, skrah, vlachoudis priority: normal severity: normal status: open title: ConfigParser._Chainmap error in 2.7.2 type: compile error versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue12717> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12717] ConfigParser._Chainmap error in 2.7.2
Mike Garabedian added the comment: Happy to help! Raymond - I came across this issue while reviewing notes from your OSCON Advanced Python talk - thanks for the great tutorial! -- ___ Python tracker <http://bugs.python.org/issue12717> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9649] wrong default for sort_keys in json module documentation
New submission from Mike Dirolf : The json module docs state that sort_keys defaults to True. From the source it looks like it actually defaults to False. Patch attached. -- assignee: d...@python components: Documentation files: sort_keys_json.patch keywords: patch messages: 114426 nosy: d...@python, mdirolf priority: normal severity: normal status: open title: wrong default for sort_keys in json module documentation versions: Python 2.7 Added file: http://bugs.python.org/file18584/sort_keys_json.patch ___ Python tracker <http://bugs.python.org/issue9649> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9924] sqlite3 SELECT does not BEGIN a transaction, but should according to spec
New submission from mike bayer :
Copying this bug from the pysqlite tracker, at
http://code.google.com/p/pysqlite/issues/detail?id=21 , as the issue has been
opened for two days with no reply. (side node - should sqlite3 bugs be reported
here or on the pysqlite tracker ?) The text below was originally written by
Randall Nortman:
Pysqlite does not open a transaction in the database until a DML statement is
encountered (INSERT, UPDATE, or DELETE). A DQL (SELECT) statement will not
cause a transaction to be opened if one is not already opened. This is the
documented behavior, but it is not what is intended by the spec (PEP 249). The
spec intends a transaction to always be open (per the spec author), and this is
what happens in other DB-API drivers. For more information, see the this
DB-SIG mailing list post (by the PEP 249 author):
http://mail.python.org/pipermail/db-sig/2010-September/005645.html
For additional background, see this thread on the SQLAlchemy mailing list,
which is the source of the attached test case:
http://groups.google.com/group/sqlalchemy/browse_thread/thread/2f47e28c1fcdf9e6/0ef1666759ce0724#0ef1666759ce0724
What steps will reproduce the problem?
1. See attached test case. Run it as is, and the final conn1.commit()
statement will complete successfully.
2. Uncomment the c2.execute("BEGIN") line and run again; this time
conn1.commit() hangs until a timeout, then a "Database is locked" error is
returned.
What is the expected output? What do you see instead?
The BEGIN should be issued implicitly, and even without doing it explicitly,
the commit should block and then return the DB locked error.
What version of the product are you using? On what operating system?
Python 2.6.6 with its built-in sqlite3 module, on Debian Squeeze x86.
import sqlite3
import os
if os.path.exists("file.db"):
os.unlink("file.db")
conn1 = sqlite3.connect("file.db")
c1 = conn1.cursor()
c1.execute("PRAGMA read_uncommitted=SERIALIZABLE")
c1.execute("""create table foo (id integer primary key, data varchar(30))""")
c1.execute("insert into foo(id, data) values (1, 'data1')")
c1.close()
conn1.commit()
c1 = conn1.cursor()
c1.execute("select * from foo where id=1")
row1 = c1.fetchone()
c1.close()
conn2 = sqlite3.connect("file.db")
c2 = conn2.cursor()
c2.execute("PRAGMA read_uncommitted=SERIALIZABLE")
# sqlite3 should be doing this automatically.
# when called, conn1's commit blocks
#c2.execute("BEGIN")
c2.execute("select * from foo where id=1")
row2 = c2.fetchone()
c2.close()
c1 = conn1.cursor()
c1.execute("update foo set data='data2'")
print "About to commit conn1..."
conn1.commit()
--
components: Library (Lib)
messages: 117167
nosy: zzzeek
priority: normal
severity: normal
status: open
title: sqlite3 SELECT does not BEGIN a transaction, but should according to spec
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue9924>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9924] sqlite3 SELECT does not BEGIN a transaction, but should according to spec
mike bayer added the comment: My own comment here is that I'm supposing the "late BEGIN" behavior is to cut down on SQLite's file locking.I think a way to maintain that convenience for most cases, while allowing the stricter behavior that makes SERIALIZABLE isolation worthwhile, would be an option to sqlite3.connect() that moves the implicit BEGIN to before any DQL, not just DML, statement. -- ___ Python tracker <http://bugs.python.org/issue9924> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9561] distutils: set encoding to utf-8 for input and output files
Changes by Mike Auty : -- nosy: +ikelos ___ Python tracker <http://bugs.python.org/issue9561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11301] cookielib.LWPCookieJar.save() doesn't save cookies
New submission from Mike Cencula : I'm trying to use cookielib.LWPCookieJar.save() to save cookies from a website. The cookie file is created with a header line, but the cookies are not stored. Example program attached. Python version: 2.5.2 (r252:60911, Jan 24 2010, 14:53:14) Running on Debian lenny as a guest on Virtualbox Output from the attached file pasted below: mike@debian:~$ python cookieexample2.py Here are the headers of the page : Server: none Content-Type: text/html Pragma: no-cache Cache-Control: no-cache Expires: Tue, 04 Dec 1993 21:29:02 GMT Vary: Accept-Encoding Date: Wed, 23 Feb 2011 20:43:55 GMT Transfer-Encoding: chunked Connection: close Connection: Transfer-Encoding These are the cookies we have received so far : 0 : 1 : 2 : 3 : 4 : mike@debian:~$ Contents of cookie.lwp afterward: mike@debian:~$ cat cookies.lwp #LWP-Cookies-2.0 mike@debian:~$ Behavior is nearly identical using cookielib.MozillaCookieJar except the headers are different in the saved cookie file. Cookies themselves are not saved. I am new to Python, so I hope this is not user error. -- components: Library (Lib) files: cookieexample2.py messages: 129223 nosy: mcencula priority: normal severity: normal status: open title: cookielib.LWPCookieJar.save() doesn't save cookies type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file20868/cookieexample2.py ___ Python tracker <http://bugs.python.org/issue11301> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11301] cookielib.LWPCookieJar.save() doesn't save cookies
Mike Cencula added the comment: User error indeed. Adding ignore_discard=True, ignore_expires=True cured the issue. Thank you. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue11301> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
