[issue45013] os.path.isfile fails on path exactly 260 Chars long in Windows
Luke Rossi added the comment: What an annoying edge case - makes sense that there isn't an easy fix. The extended path prefix worked perfectly - thanks -- ___ Python tracker <https://bugs.python.org/issue45013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45013] os.path.isfile fails on path exactly 260 Chars long in Windows
Luke Rossi added the comment: I saw 33105, but believe this to be a different issue as path length 260 is valid. I did testing by crafting a path that is exactly 260 by hand - A path 259 in length reports .isfile() as True. The Stack Error: [WinError 3] The system cannot find the path specified -- ___ Python tracker <https://bugs.python.org/issue45013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45013] os.path.isfile fails on path exactly 260 Chars long in Windows
New submission from Luke Rossi : I saw 33105, but believe this to be a different issue as path length 260 is valid. I did testing by crafting a path that is exactly 260 by hand - A path 259 in length reports .isfile() as True. -- components: Library (Lib) messages: 400341 nosy: serhiy.storchaka, ubermidget2 priority: normal severity: normal status: open title: os.path.isfile fails on path exactly 260 Chars long in Windows type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue45013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44705] Support Windows file open modes for `open` built-in function
New submission from Luke Deller : Microsoft Windows supports some extra file open modes including: "S"Specifies that caching is optimized for, but not restricted to, sequential access from disk. "T"Specifies a file as temporary. If possible, it is not flushed to disk. "D"Specifies a file as temporary. It is deleted when the last file pointer is closed Python 2 used to allow "T" and "D" flags in the built-in `open` function (though this was not documented): https://github.com/python/cpython/blob/2.7/Objects/fileobject.c#L214 It would be great if these flags were allowed in Python 3. I see that Python3 implementation uses `open`/`_wopen` rather than `fopen` now. The mapping to numeric flags for `_wopen` is shown in the documentation here: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fopen-wfopen (search for "Equivalent oflag value") -- components: IO messages: 397971 nosy: lukedeller1 priority: normal severity: normal status: open title: Support Windows file open modes for `open` built-in function type: enhancement versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34027] python 3.7 openpty/forkpty build failure using nix package manager macOS environment
Luke Granger-Brown added the comment: Still seems to be a problem with everything up to Py3.11. -- nosy: +lukegb versions: +Python 3.10, Python 3.11, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue34027> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42723] Unclear why dict unpacking cannot be used in dict comprehension
New submission from Luke Davis :
Why am I unable to do:
dict = { **sub_dict for sub_dict in super_dict.values() }
which throws: "dict unpacking cannot be used in dict comprehension"
Whereas the equivalent code below doesn't throw any errors?:
dict = {}
for sub_dict in super_dict.values():
dict = { **dict, **sub_dict }
Am I wrong in thinking the first and second block of code should do the same
thing behind the scenes?
--
messages: 383641
nosy: PartlyFluked
priority: normal
severity: normal
status: open
title: Unclear why dict unpacking cannot be used in dict comprehension
type: enhancement
___
Python tracker
<https://bugs.python.org/issue42723>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34453] ipaddress module accepts some strange IPv6 addresses that it shouldn't
Luke Kenneth Casson Leighton added the comment: that's interesting, michael: it means that all of the IPv6 validators online are wrong, like this one! https://formvalidation.io/guide/validators/ip/ -- ___ Python tracker <https://bugs.python.org/issue34453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34428] tokenize
Luke Kenneth Casson Leighton added the comment: yep good call terry, not getting any response from the autopep8 developer, and i believe it was down to a loop where the text is being thrown line-by-line at tokenize and it was losing critical state information. so... not a bug in tokenize. -- ___ Python tracker <https://bugs.python.org/issue34428> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34453] ipaddress module accepts some strange IPv6 addresses that it shouldn't
Luke Kenneth Casson Leighton added the comment: hi prudvi: i have absolutely no idea. i am simply running test validators online, which show and confirm that they are correctly INVALID. a google search shows a number of IPv6 validators: https://www.google.co.uk/search?q=ipv6+address+validator i have absolutely no actual knowledge of what constitutes a valid IPv6 address or not, nor know of any "official" resources. all i know is: consensus tends to agree that these two addresses are accepted by the python ipaddress module when they should not. -- ___ Python tracker <https://bugs.python.org/issue34453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34453] ipaddress module accepts some strange IPv6 addresses that it shouldn't
Luke Kenneth Casson Leighton added the comment: > Hi lkcl, are you working on the fix? I'd like to work on it. hi prudvi, i'm not: i'm simply making people aware that there's an issue that needs to be addressed (pun intended) -- ___ Python tracker <https://bugs.python.org/issue34453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34453] ipaddress module accepts some strange IPv6 addresses that it shouldn't
New submission from Luke Kenneth Casson Leighton : adding some unit tests to some code being written, searched randomly on the internet for an IPv6 test suite and found one in php *shudder* # https://github.com/gws/ipv6-address-test/blob/master/Tests/Ipv6TestCase.php converted it to python, and was surprised to find that there are two cases which the ipaddress.IPv6Address module accepts, that it should not! attached is a quick-and-dirty hacked together unit test which shows the issue. the full suite may be found here (over 400 ipv6 addresses to test): https://github.com/threefoldtech/jumpscale_core/blob/development_dynamic/tests/jumpscale_test/test10_j_data_types.py -- components: Tests files: ipv6test.py messages: 323843 nosy: lkcl priority: normal severity: normal status: open title: ipaddress module accepts some strange IPv6 addresses that it shouldn't type: behavior versions: Python 3.5, Python 3.6 Added file: https://bugs.python.org/file47757/ipv6test.py ___ Python tracker <https://bugs.python.org/issue34453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34428] tokenize
Luke Kenneth Casson Leighton added the comment: ahh darn-it, autopep8 is passing in tokens line-by-line, to be parsed one at a time oh and of course it's losing state information that tokenizer critically relies on. i *think* that's what's going on so it's highly unlikely to be a python tokenize bug... can we wait to see what the autopep8 developer says? -- ___ Python tracker <https://bugs.python.org/issue34428> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34428] tokenize
Luke Kenneth Casson Leighton added the comment:
wtf??? neither can i
import io
import tokenize
text = r'''\
(
r"\(")
(
"\(")
'''
string_io = io.StringIO(text)
tokens = list(
tokenize.generate_tokens(string_io.readline)
)
print (tokens)
works perfectly.
ok a i bet you it's something to do with how
string_io.readline works, or something to do with
the format of the text. give me a sec to triage it.
--
___
Python tracker
<https://bugs.python.org/issue34428>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34428] tokenize
Luke Kenneth Casson Leighton added the comment:
regular expressions are not something i am familiar or comfortable
with (never have been: the patterns are too dense). however REMOVING
"Bracket" from the regular expression(s) for PseudoToken "fixes"
the problem.
some debug print statements dropped in at around line 640 of
tokenize.py show that the match on the "working" code
with r"\(") as input gives a start/end/spos/epos that is DIFFERENT
from when the same code is given just "\("
line 'r"\\(")\n'
pos 0 7 r <_sre.SRE_Match object; span=(0, 5), match='r"\\("'>
pseudo start/end 0 5 (2, 0) (2, 5)
vs
line '"\\(")\n'
pos 0 6 " <_sre.SRE_Match object; span=(0, 4), match='"\\("'>
pseudo start/end 0 4 (5, 0) (5, 4)
there *may* be a way to "fix" this by taking out the pattern
matching on Bracket and prioritising everything else.
while pos < max:
pseudomatch = _compile(PseudoToken).match(line, pos)
print ("pos", pos, max, line[pos], pseudomatch)
if pseudomatch:# scan for tokens
start, end = pseudomatch.span(1)
spos, epos, pos = (lnum, start), (lnum, end), end
print ("pseudo start/end", start, end, spos, epos)
if start == end:
continue
Bracket = '[][(){}]'
Special = group(r'\r?\n', r'\.\.\.', r'[:;.,@]')
# REMOVE Bracket
Funny = group(Operator, Special)
PlainToken = group(Number, Funny, String, Name)
Token = Ignore + PlainToken
# First (or only) line of ' or " string.
ContStr = group(StringPrefix + r"'[^\n'\\]*(?:\\.[^\n'\\]*)*" +
group("'", r'\\\r?\n'),
StringPrefix + r'"[^\n"\\]*(?:\\.[^\n"\\]*)*' +
group('"', r'\\\r?\n'))
PseudoExtras = group(r'\\\r?\n|\Z', Comment, Triple)
PseudoToken = Whitespace + group(PseudoExtras, Number, Funny, ContStr, Name)
--
nosy: -serhiy.storchaka
___
Python tracker
<https://bugs.python.org/issue34428>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34428] tokenize
Luke Kenneth Casson Leighton added the comment: python2.7 and 3.5 also has exact same issue. -- versions: +Python 2.7, Python 3.5 ___ Python tracker <https://bugs.python.org/issue34428> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34428] tokenize
Luke Kenneth Casson Leighton added the comment:
these two line also pass (do not throw an exception):
co = re.compile(
r"\(")
the code that fails may be further reduced to the following:
(
"\(")
--
___
Python tracker
<https://bugs.python.org/issue34428>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34428] tokenize
New submission from Luke Kenneth Casson Leighton :
https://github.com/hhatto/autopep8/issues/414
the following two lines of code are not parseable by tokenize.py:
co = re.compile(
"\(")
the combination of:
* being split on two lines
* having a backslash inside quotes
* having a bracket inside quotes
is an edge-case that _tokenize cannot cope with.
--
components: Library (Lib)
messages: 323698
nosy: lkcl
priority: normal
severity: normal
status: open
title: tokenize
type: crash
versions: Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue34428>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27487] -m switch regression in Python 3.5.2 (under rare circumstances)
Luke added the comment: I recently started getting this warning message (see bottom) that seems to be due to the changes from this issue. I'm running a submodule as main using the `-m` flag, but I'm not doing any modification to `sys.modules`, or even `sys.path`... I've taken a look at [The double-import trap](http://python-notes.curiousefficiency.org/en/latest/python_concepts/import_traps.html#the-double-import-trap), but it doesn't really seem to apply. I really have no idea how to go about debugging this. 1) Would it be possible for the warning to include information about how/where the double import is happening? 2) Are there other, common ways of this occurring when the `sys` module isn't being messed with? The issue on stackexchange (https://stackoverflow.com/questions/43393764/python-3-6-project-structure-leads-to-runtimewarning) seems similar, although this one in particular isn't reproducible. Any help would be greatly appreciated. Thanks! File "/n/home00/lkelley/.conda/envs/py35/lib/python3.6/runpy.py", line 183, in _run_module_as_main mod_name, mod_spec, code = _get_module_details(mod_name, _Error) File "/n/home00/lkelley/.conda/envs/py35/lib/python3.6/runpy.py", line 125, in _get_module_details warn(RuntimeWarning(msg)) File "/n/home00/lkelley/.conda/envs/py35/lib/python3.6/warnings.py", line 99, in _showwarnmsg msg.file, msg.line) File "/n/home00/lkelley/zcode/zcode/inout/inout_core.py", line 835, in warn_with_traceback traceback.print_stack() /n/home00/lkelley/.conda/envs/py35/lib/python3.6/runpy.py:125: RuntimeWarning: 'mbhmergers.gwb.deterministic.grid_calc' found in sys.modules after import of package 'mbhmergers.gwb.deterministic', but prior to execution of 'mbhmergers.gwb.deterministic.grid_calc'; this may result in unpredictable behaviour warn(RuntimeWarning(msg)) -- nosy: +lzkelley ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27487> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30203] AttributeError in Popen.communicate()
Luke Campagnola added the comment: Update: this appears to be the prior exception that causes _communication_started and _fileobj2ouput to be out of sync: File "/usr/lib/python3.5/subprocess.py", line 1072, in communicate stdout, stderr = self._communicate(input, endtime, timeout) File "/usr/lib/python3.5/subprocess.py", line 1672, in _communicate self.stdin.flush() ValueError: flush of closed file -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30203] AttributeError in Popen.communicate()
New submission from Luke Campagnola:
In my application, calling communicate() on a Popen instance is giving the
following exception:
. . .
File "/usr/lib/python3.5/subprocess.py", line 1072, in communicate
stdout, stderr = self._communicate(input, endtime, timeout)
File "/usr/lib/python3.5/subprocess.py", line 1693, in _communicate
stdout = self._fileobj2output[self.stdout]
AttributeError: 'Popen' object has no attribute '_fileobj2output'
I have not been able to reproduce this in a simple example, but I imagine this
could happen if Popen._communicate() raises an exception in the first 20 lines
or so--this would cause _communication_started to be set True, even though
_fileobj2output has not been initialized.
I suggest setting self._fileobj2output = None in Popen.__init__() and changing
the relevant code in _communicate() from
if not self._communication_started:
self._fileobj2output = {}
to:
if self._fileobj2output is None:
self._fileobj2output = {}
--
messages: 292575
nosy: Luke Campagnola
priority: normal
severity: normal
status: open
title: AttributeError in Popen.communicate()
type: behavior
versions: Python 3.5
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30203>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a cross-compilation target
Luke Taylor added the comment: Ok, great! On Fri, Jun 3, 2016 at 7:34 AM Luke Taylor <l...@deentaylor.com> wrote: > Ah, cool! > On Fri, Jun 3, 2016 at 2:58 AM Russell Keith-Magee <rep...@bugs.python.org> > wrote: > >> >> Russell Keith-Magee added the comment: >> >> Yes - I'm aware of Pythonista; the author of that app contracted me to >> develop the 3.5 patch that is attached to this ticket :-) >> >> -- >> >> ___ >> Python tracker <rep...@bugs.python.org> >> <http://bugs.python.org/issue23670> >> ___ >> > -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a cross-compilation target
Luke Taylor added the comment: Are you aware of Pythonista? I have no affiliation, but I'm a fan of the app and the community surrounding it. See http://omz-software.com/pythonista/ for details. I'm sure communication with the developer of the app could yield some useful insights. -- nosy: +Luke Taylor ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26847] filter docs unclear wording
Luke added the comment: For shame! ... I deserved that callout. :S My examples should have included the cast to bool, which is indeed not the same as the values' being "equal to False" in themselves... I didn't realize that "is false" was conventional shorthand for that cast and comparison. Thanks! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26847> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26847] filter docs unclear wording
Luke added the comment: josh, we're saying the same thing but misunderstanding each other. :) I realize that they can be empty containers, etc., and that's why I think "equal to False" is appropriate -- because those things *are* equal to False: >>> [] == False True >>> 0 == False True etc. However, they are not identical to False: >>> [] is False False >>> 0 is False False And that's why I think the wording "are false" is potentially misleading. Perhaps there's a better wording than "equal to False" (compares equivalently to False? or simply: are falsey? :p), but anyhow, we're identifying the same behaviour here. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26847> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26847] filter docs unclear wording
New submission from Luke: The current docs for both filter and itertools.filterfalse use the following wording (emphasis added): all elements that are false are removed returns the items that are false This could be confusing for a new Python programmer, because the actual behaviour is that elements are equality-compared, not identity-compared. Suggested wording: "are equal to False" https://docs.python.org/3.5/library/functions.html#filter https://docs.python.org/3.5/library/itertools.html#itertools.filterfalse -- assignee: docs@python components: Documentation messages: 264206 nosy: docs@python, unfamiliarplace priority: normal severity: normal status: open title: filter docs unclear wording type: enhancement versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26847> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26255] symtable.Symbol.is_referenced() returns false for valid use
New submission from Luke Schubert:
If the following function is saved in listcomp.py:
def encode(inputLetters):
code = {'C':'D', 'F':'E'}
return set(code[x] for x in inputLetters)
and the following code is used to create a symtable for this function:
import symtable
if __name__ == "__main__":
fileName = 'listcomp.py'
f = open(fileName, 'r')
source = f.read()
table = symtable.symtable(source, fileName, 'exec')
children = table.get_children()
for childTable in children:
symbols = childTable.get_symbols()
for s in symbols:
if (not s.is_referenced()):
print ("Unused symbol '%s' in function '%s'"
% (s.get_name(), childTable.get_name()))
then is_referenced() returns false for the 'code' symbol.
If the following function is saved instead:
def encode2(inputLetters):
code = {'C':'D', 'F':'E'}
return [ code[x] for x in inputLetters ]
then is_referenced() returns true for the 'code' symbol.
Possibly I'm misunderstanding what is_referenced() means, but I thought it
should return true in both cases?
--
messages: 259316
nosy: luke.schubert
priority: normal
severity: normal
status: open
title: symtable.Symbol.is_referenced() returns false for valid use
versions: Python 2.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26255>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12346] Python source code build fails with old mercurial
Luke Erlacher added the comment: This is not fixed in 2.7.10. -- nosy: +Luke Erlacher ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12346> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24627] Import bsddb result in error on OS X (Python 2.7.10)
New submission from Luke Jang: As title. I installed Python using brew. $ python Python 2.7.10 (default, Jul 9 2015, 13:34:07) [GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin Type help, copyright, credits or license for more information. import bsddb Traceback (most recent call last): File stdin, line 1, in module File /usr/local/Cellar/python/2.7.10_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/bsddb/__init__.py, line 67, in module import _bsddb ImportError: No module named _bsddb -- components: Library (Lib) messages: 246682 nosy: Luke Jang priority: normal severity: normal status: open title: Import bsddb result in error on OS X (Python 2.7.10) versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24627 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Changes by Luke Dunstan lukedunsta...@gmail.com: -- nosy: +Luke.Dunstan versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17797 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5051] test_update2 in test_os.py invalid due to os.environ.clear() followed by reliance on environ COMSPEC
Luke Kenneth Casson Leighton added the comment: that's not the correct solution, ned. what that will do is when someone runs a combination of python and MSYS under wine, the test will be skipped incorrectly. thanks to the work that i did back in 2009, wine has now been improved significantly and has been capable of running python correctly for over 3 years now. i use it to do testing of pyjamas-desktop. bottom line: skipping regression tests by making assumptions based solely and exclusively on the platform type is not good news. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5051 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5051] test_update2 in test_os.py invalid due to os.environ.clear() followed by reliance on environ COMSPEC
Luke Kenneth Casson Leighton added the comment: hi ned, well, the situation surrounding the bug-reporting that i was doing at the time was a general campaign of this person is obviously wasting our time because they're developing yet another port/platform, that is obviously a waste of our time, therefore we will shut him down and ban him from the bugtracker and thus generally make our lives easier. so against that background i really wasn't inclined to contribute to the development of python. the argument given for this specific bug [off-list because i had been ordered not to use the bugtracker] was it's not a supported combination therefore obviously it's not a bug. leaving that aside, and assuming that things have moved on from there and that improvements to python and its expansion into areas beyond where it is currently entrenched are welcomed, the arguments given 3 years ago are actually valid... but from a different perspective: the combination of win32 and bash is particularly weird [i.e. borderline] and thus the test is incomplete. so it would be best i feel to consider what the test is trying to achieve: set environment variables, and then execute a command that results in that environment variable being passed and read back with python's popen command. in the POSIX case, the easiest way to do that would involve using /bin/sh - a pretty standard baseline application that can be expected to exist on every POSIX platform under the sun. but the most generic case would actually involve compiling a small c application which read - in c - a standard environment variable - and printf'd it then exited. a quick google search c getenv shows a perfect example: http://msdn.microsoft.com/en-gb/library/aa246422%28v=vs.60%29.aspx so the *ideal* situation i feel would be to use a shortened version of that, with the env variable HELLO printf'd out. if python popen returns world, the test can be deemed to be successful. the less-than-ideal situation would be, rather than to skip the test, to use command.com or cmd.exe under win32 rather than executing /bin/sh... ... but the irony is that even if you did that, you would run into the same bug because the os.environ.clear() destroys the COMSPEC environment variable! soooOoo.. to fix that, you'd need to record the COMSPEC environment variable just before the os.environ.clear() and re-establish it prior to the popen. so it's a tricky one! * the ideal test is to actually compile up some c code. that would however mean shipping a binary with the python distribution as part of the test suite [eek! there must be other solutions...] * the less-than-ideal test is to use a pre-existing application, but then you have to work out, on a per-supported-platform basis, an OS-specific method of echoing an environment variable * the least perfect method is to skip the test entirely on platforms that don't have /bin/sh, but then you have the situation where the regression tests aren't actually doing their job, thus defeating the goal of python being a platform-independent environment because you can't rely on code working across all platforms. tricky one! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5051 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17340] Handle malformed cookie
Luke Plant added the comment: I'm a core developer on Django, and I've looked into cookies a lot, and also Python's SimpleCookie, and I've found that all accepted RFCs are completely irrelevant for this issue. No accepted RFC was ever widely implemented - instead browsers mainly did something like the original Netscape cookies, with various interpretations. Opera attempted RFC 2965, at least at one point, but no-one else. RFC 6265, whatever its status, is probably the closest thing to a useful document of how cookies should work. But even then, I'm afraid that the main guiding principle has to be sheer pragmatism. Read the source code or bug trackers of any other project that has to handle cookies and you'll find they have all come to that conclusion, unfortunately. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17340 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw* hosts
Luke Kenneth Casson Leighton added the comment: the last time this was brought up on python-dev the opinions of the primary python developers was made very very clear: anything that is not written by them is treated with extreme hostile and predudicial contempt. what i mean by that is that the view of the primary python developers is that when they make decisions to decrease their workload, other people are *NOT* welcome to question those decisions. [i questioned their decisions; all bugreports were terminated with excuses without good technical justification, and when i questioned those, access to the bugtracker was terminated]. roumen's work should have been encouraged and welcomed when it was first initiated - FIVE years ago. the best bet therefore is to go over the heads of the primary python developers and to approach the Python Software Foundation's Board of Directors. they are required to enact the PSF Charter in the best interests of the Python Programming Language. what the existing primary python developers can or cannot cope with is of secondary consequence for the Board. the main concern of the primary python developers was that they would be landed with yet another platform to support, and, as they are struggling to cope with the existing ones, they made - and make - absolutely any excuse that they can, regardless of actual merit, to ensure that no other platforms are added. roumen, my opinion is that you have demonstrated over the past five years that you are committed to ensuring that python gets mingw support, and that you yourself are the best person to become the maintainer of python-mingw. you are, already, de-facto, its maintainer. answering some other points: * python-mingw actually requires an entire new platform (built in to sys and os at a fundamental level). neither the platform rules for cygwin, nor the platform rules for gcc, *nor* the platform rules for win32 correctly apply. the MSVC platform rules should also be obviously understood to be useless. mingw uses gcc, but it is gcc for win32: it therefore falls through *all* the existing platforms and requires its own separate class in distutils. * the autoconf-generated pyconfig.h is so insanely slow to generate under mingw (any configure script running under MSYS is insanely slow) that it is virtually impossible to do any development. also, the hard-coded config header file for win32 is also useless: firstly mingw doesn't have all the features of win32 (the headers are reverse-engineered and so are incomplete). secondly, the hard-coded config header file for win32 has MSVC-specific details in it that make it useless. * distutils was frozen because several immature developers made improperly tested commits that caused massive disruption. rather than put in proper review procedures, the primary python developers decided to terminate all possibility of ever adding in a new platform - ever - and began distutils2. this situation has to be reversed. mingw *requires* that distutils have support for the mingw compiler. a way to achieve this is to add separate files into distutils (which cannot be questioned as to their effect on existing files in distutils, because they are separate and therefore have zero effect), and then, once those files have been added and accepted, create a *ONE* line patch to distutils which pulls in the new mingw distutils functionality. a one-line patch cannot really be argued with, esp. if it is only an include. roumen and others: i recommend that you approach the Python Software Foundation and ask that this project be sponsored for 3 months and/or until it is completed and the patches are in. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16708] Module: shutil will not import when writen in the text editor but will in the python shell
Changes by luke wood dj_...@live.com: -- components: Library (Lib) files: dropbox dropper.py nosy: dj_law priority: normal severity: normal status: open title: Module: shutil will not import when writen in the text editor but will in the python shell type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file28346/dropbox dropper.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16708 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16708] Module: shutil will not import when writen in the text editor but will in the python shell
luke wood added the comment: ok i dont really know what python list is. i googled it but it just came up with the documentation. Traceback (most recent call last): File C:\Users\luke\Documents\Python Code\dropbox dropper.py, line 1, in module import shutil File C:\Python33\lib\shutil.py, line 14, in module import tarfile File C:\Python33\lib\tarfile.py, line 48, in module import copy File C:\Users\luke\Documents\Python Code\copy.py, line 4, in module shutil.copy2(source, destination) AttributeError: 'module' object has no attribute 'copy2' -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16708 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with packaging
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: distutils2 is the place to add such new features. you're not getting it. you've just told both this mingw32 project and also the new effort by ray that they can go fuck themselves, because their efforts are a total waste of time (as far as python 2 is concerned). why? because without patches to python 2 distutils, you're condemning their work to total irrelevance. why? because nobody in their right mind is going to do what you suggest - go educate people about using distutils2. that's tens of thousands of package maintainers, and you're expecting *two* people to do that job - you must be off your head if you think that's even remotely realistic! i can't quite understand why you would even make such a recommendation, because it's so clearly unworkable and unrealistic. now, if python2 was in any way going to die, be totally irrelevant or otherwise be superceded at any time in the next ten years i would in no way be so pissed at this freeze, and would in no way bother to comment on this. i don't like doing this sort of thing: it makes me look like i'm some sort of fucking idiot - but that's tough luck on me. someone has to tell it straight, and truthfully say the things that everyone else doesn't have the balls to say. what has me particularly pissed off is that the freeze happened years *AFTER* roumen created this initial patch. also what has me particularly pissed off is that the freeze happened because *other people* - not roumen, and not ray - didn't do their job, either in checking that their modifications to distutils would have an impact on any other ports, but more than that, neither did anyone else in the python team. why should ray and roumen's work be made insultingly irrelevant, just because of mistakes made by *other people*? by complete contrast, i absolutely agree with you 100% that in NO WAY should any modifications to distutils in python3 sources be EVER permitted. forcing people to use distutils2 for *new* packages, as well as packages being transitioned to python3, and documenting that fact (and the required procedure to be followed) prominently on the python web site, is perfectly reasonable. the reason why it is perfectly reasonable is because the developer who is writing the new package (or transitioning the old one) is *actively* taking the steps - THEY are taking steps - THEY are the ones ACTIVELY doing the work. intiated BY THEM. people PLURAL. tens of THOUSANDS of people. and those people will read documentation, and will ask questions on the mailing list, and will generally follow the advice and guidance of the community. contrast this with a completely unrealistic expectation that TWO people must DEMAND of those exact same tens of thousands of python2 developers that ohhh, you muuust use distutils2 and you can perhaps appreciate why i am not exactly impressed. of course, if the Python Software Foundation is offering to fund these two developers with a campaign to educate the entire world of python2 package maintainers with the demand that they all convert to distutils2, and is willing to support them by creating a write-up and a series of articles and other supporting documentation on the python.org web site, then that is an entirely different matter. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with packaging
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: The feature freeze applies to all branches. Even when 3.4 starts, the same rule that has been repeatedly explained for two years will apply: no new features in distutils. Again, neither Tarek nor I are happy about that, but it was the decision taken by python-dev due to the big number of setup.py scripts depending on undocumented behavior, bugs and quirks. then you use monkeypatching. split the new functionality into a separate module - /distutils/mingw.py - that is called by a clear ONE LINE modification in distutils.py that CLEARLY cannot have IN ANY WAY not one SINGLE effect on ANY OTHER python port. that line would be something like: if sys.compiler == 'mingw32': import distutils.mingw within that distutils.mingw it would monkey-patch distutils to add itself into the distutils code. the same technique could be used by ray to monkey-patch the cygwin compiler by doing this: distutils/specialportmaintainedbyray.py: distutils.cygwincompiler.RE_VERSION = re.compile(b'[\D\s]*(\d+\.\d+(\.\d+)*)[\D\s]*$') of course, for this to work, support for the ports are required (identification of the ports) down at the sys.py and os.py level. unless you expect these port maintainers to put in special monkeypatching into the c-code itself (which would of course be conditionally compiled and would in no way affect ANY other port of python). this would be perfectly reasonable. the impact on other ports would be zero. consideration of the one line patch would take a few minutes. ... and for those packages that depend on undocumented behaviour? in the unlikely event that they ever get compiled for mingw32 or ray's port, well, the person who compiled such a package would encounter an error, and would wonder why it was broken, and then would get onto a mailing list and go i have a problem, can anyone help me. chances are that the majority of packages would however compile cleanly. there's always a way. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9216] FIPS support for hashlib
Luke Carrier h...@lukecarrier.me added the comment: I've not done enough digging on the issue I'm presently experiencing to draw any conclusions make any suggestions, but this change seems to break the present distribute module (version 0.6.27). It appears it will likely break a great deal of other code too. I've pasted the relevant output here and attached the full traceback. File /usr/lib64/python3.2/hashlib.py, line 112, in __get_openssl_constructor f(usedforsecurity=False) TypeError: openssl_md5() takes no keyword arguments Whilst I agree with the notion behind this change, Fedora's quick actions have led to me spending the best part of an hour of the night before ship day diagnosing issues caused by undocumented (or at least under-documented) changes to code I haven't written or interfaced with. _Please_ publicise the change a little better? Pretty please!? -- nosy: +lukecarrier Added file: http://bugs.python.org/file26205/virtualenv_distribute ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9216 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14683] os.path.isdir.__name__ is _isdir on Windows (2.7.3)
New submission from Luke McCarthy l...@iogopro.co.uk: This caused something to break in our code. I know, maybe it shouldn't rely on that. -- messages: 159460 nosy: shaurz priority: normal severity: normal status: open title: os.path.isdir.__name__ is _isdir on Windows (2.7.3) versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14683 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14282] lib2to3.fixer_util.touch_import('__future__', ...) can lead to SyntaxError in code
Luke Macken lmac...@redhat.com added the comment: Yep, that seems like the right solution. Thanks, Martin. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14282 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14282] lib2to3.fixer_util.touch_import('__future__', ...) can lead to SyntaxError in code
New submission from Luke Macken lmac...@redhat.com:
Problem:
lib2to3.fixer_util.touch_import('__future__', ...) will insert the import
statement below all other imports. This will then trigger the following error:
SyntaxError: from __future__ imports must occur at the beginning of the file
How to reproduce the issue (using modernize, which uses lib2to3):
$ git clone https://github.com/mitsuhiko/python-modernize.git
$ cd python-modernize
$ echo EOF test.py
# test.py
Test case for lib2to3.fixer_util.touch_import('__future__', ...)
import os
print hi
EOF
$ python modernize.py test.py
--- test.py (original)
+++ test.py (refactored)
@@ -1,4 +1,5 @@
# test.py
Test case for lib2to3.fixer_util.touch_import('__future__', ...)
import os
-print hi
+from __future__ import print_function
+print(hi)
$ python3 test.py
File test.py, line 4
from __future__ import print_function
^
SyntaxError: from __future__ imports must occur at the beginning of the
file
The following patch to lib2to3 seems to solve the issue:
--- /usr/lib64/python2.7/lib2to3/fixer_util.py.orig 2012-03-09
21:53:10.841083479 -0800
+++ /usr/lib64/python2.7/lib2to3/fixer_util.py 2012-03-09
21:58:18.678946683 -0800
@@ -306,14 +306,15 @@
# figure out where to insert the new import. First try to find
# the first import and then skip to the last one.
insert_pos = offset = 0
-for idx, node in enumerate(root.children):
-if not is_import_stmt(node):
-continue
-for offset, node2 in enumerate(root.children[idx:]):
-if not is_import_stmt(node2):
-break
-insert_pos = idx + offset
-break
+if package != '__future__':
+for idx, node in enumerate(root.children):
+if not is_import_stmt(node):
+continue
+for offset, node2 in enumerate(root.children[idx:]):
+if not is_import_stmt(node2):
+break
+insert_pos = idx + offset
+break
# if there are no imports where we can insert, find the docstring.
# if that also fails, we stick to the beginning of the file
After the patch, all is well:
$ python modernize.py test.py
--- test.py (original)
+++ test.py (refactored)
@@ -1,4 +1,5 @@
# test.py
Test case for lib2to3.fixer_util.touch_import('__future__', ...)
+from __future__ import print_function
import os
-print hi
+print(hi)
$ python3 test.py
hi
--
components: 2to3 (2.x to 3.x conversion tool)
messages: 155569
nosy: lmacken
priority: normal
severity: normal
status: open
title: lib2to3.fixer_util.touch_import('__future__', ...) can lead to
SyntaxError in code
type: behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14282
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14282] lib2to3.fixer_util.touch_import('__future__', ...) can lead to SyntaxError in code
Changes by Luke Macken lmac...@redhat.com: -- keywords: +patch Added file: http://bugs.python.org/file24814/python-lib2to3-touch-future-import.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14282 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13637] binascii.a2b_* functions could accept unicode strings
Luke-Jr luke...@users.sourceforge.net added the comment: Has this been fixed in 3.2 yet? Somehow it seems to have been reclassified as an enhancement when it's really a regression. str worked fine in these functions in 3.1. -- nosy: +luke-jr ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13637 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Luke Plant l.plant...@cantab.net added the comment: David, Thanks again for the time on this. Can I push to get the patches included, or is there work that still needs to be done on the patches now that the idea is accepted in principle? I did experiment with a few approaches to implement, and it seemed like the most sensible. Thanks, Luke -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2193 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with packaging
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: eric, if you recall there was some discussion that it was acceptable to use distutils but *only* for python 2.N (on the basis that its use is so well entrenched that it would be impossible to force python2.N applications to start using distutils2), and i agreed wholeheartedly with you that the expectation to use distutils2 would be reasonable for python3.N just as an aside: have all python 3.N packaging scripts, for all python-dev scripts *and* all 3rd party packages world-wide, been using distutils2 by default instead of distutils? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12488] multiprocessing.Connection does not communicate pipe closure between parent and child
New submission from Luke lcamp...@email.unc.edu: I have found that when using multiprocessing.Connection objects to pass data between two processes, closing one end of the pipe is not properly communicated to the other end. My expectation was that when calling recv() on the remote end, it should raise EOFError if the pipe has been closed. Instead, the remote recv() blocks indefinitely. This behavior exists on Linux and Cygwin, but NOT on native Windows. Example: import multiprocessing as m def fn(pipe): print recv:, pipe.recv() print recv:, pipe.recv() if __name__ == '__main__': p1, p2 = m.Pipe() pr = m.Process(target=fn, args=(p2,)) pr.start() p1.send(1) p1.close() ## should generate EOFError in remote process -- messages: 139754 nosy: lcampagn priority: normal severity: normal status: open title: multiprocessing.Connection does not communicate pipe closure between parent and child type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12488 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12488] multiprocessing.Connection does not communicate pipe closure between parent and child
Luke lcamp...@email.unc.edu added the comment: That's interesting, thanks for your response. It is also a bit awkward.. Might I recommend adding a note to the documentation? It is not really intuitive that each child should need to close the end of the pipe it isn't using (especially since it is possible to create a child that has no explicit access to that end of the pipe, even though it has inherited the file descriptor). 2011/7/4 Charles-François Natali rep...@bugs.python.org Charles-François Natali neolo...@free.fr added the comment: That's because the other end of the pipe (p1) is open in the child process (FDs are inherited on fork()). Just add p1.close() at the beginning of fn() and you'll get EOF. Closing as invalid. -- nosy: +neologix resolution: - invalid stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12488 ___ -- Added file: http://bugs.python.org/file22569/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12488 ___That#39;s interesting, thanks for your response.divbr/divdivIt is also a bit awkward.. divMight I recommend adding a note to the documentation? It is not really intuitive that each child should need to close the end of the pipe it isn#39;t using (especially since it is possible to create a child that has no explicit access to that end of the pipe, even though it has inherited the file descriptor). br divbrbrdiv class=gmail_quote2011/7/4 Charles-François Natali span dir=ltrlt;a href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;/spanbrblockquote class=gmail_quote style=margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex; br Charles-François Natali lt;a href=mailto:neolo...@free.fr;neolo...@free.fr/agt; added the comment:br br That#39;s because the other end of the pipe (p1) is open in the child process (FDs are inherited on fork()).br Just addbr p1.close()br br at the beginning of fn() and you#39;ll get EOF.br Closing as invalid.br br --br nosy: +neologixbr resolution:  -gt; invalidbr stage:  -gt; committed/rejectedbr status: open -gt; closedbr divdiv/divdiv class=h5br ___br Python tracker lt;a href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;br lt;a href=http://bugs.python.org/issue12488; target=_blankhttp://bugs.python.org/issue12488/agt;br ___br /div/div/blockquote/divbr/div/div/div ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Luke Plant l.plant...@cantab.net added the comment: First, I agree with others who say that RFCs are basically irrelevant for cookies. For Django we've discovered this in various ways e.g. issue 9824 - http://bugs.python.org/issue9824 - which has now been applied. We have also had to work around the stdlib behaviour here. Second, I have implemented a patch for this, with tests, against trunk - please review. After looking at the implementation, this seems like the best way to make Python conservative in what is produces and liberal in what it accepts, which seems to be what the thread converged on. BaseCookie will now silently discard cookie 'morsels' with a colon in their name (and all other irregularities) when loading from a string, rather than raise an exception. This allows cookie parsing to continue, so that other cookies in the HTTP header will be found. However, if in Python code you attempt to directly set a morsel with an illegal name, you will still get the error. There is a more lax strategy: Simply add ':' to the _LegalChars variable. This would allow morsels to be *read* that have a colon in their name. However, from the current implementation, it would be very hard to add that ability without also allowing the BaseCookie class to produce such cookies. This would also raise other issues about at what point an error should be raised for setting invalid cookies etc. Also, allowing these illegal cookies to be read is a corner case that is much less important - it isn't needed either for Trac or for our needs in Django. For these reasons, I decided against the more lax strategy. -- keywords: +patch nosy: +spookylukey Added file: http://bugs.python.org/file22513/issue2193_patch_trunk.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2193 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Luke Plant l.plant...@cantab.net added the comment: Same patch backported to python 2.7 branch -- Added file: http://bugs.python.org/file22514/issue2193_patch_python27.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2193 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Luke Plant l.plant...@cantab.net added the comment: Found a bug with patch - this supersedes old one. -- Added file: http://bugs.python.org/file22515/issue2193_patch_2_trunk.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2193 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Luke Plant l.plant...@cantab.net added the comment: Same against Python 2.7 -- Added file: http://bugs.python.org/file22516/issue2193_patch_2_python27.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2193 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Changes by Luke Plant l.plant...@cantab.net: Removed file: http://bugs.python.org/file22513/issue2193_patch_trunk.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2193 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Changes by Luke Plant l.plant...@cantab.net: Removed file: http://bugs.python.org/file22514/issue2193_patch_python27.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2193 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Luke Plant l.plant...@cantab.net added the comment: I had a quick look, and there are these relevant bits: There are two audiences for this specification: developers of cookie-generating servers and developers of cookie-consuming user agents. And: To maximize interoperability with user agents, servers should limit themselves to the well-behaved profile defined in Section 4 when generating cookies. So, the document doesn't tell servers how to parse cookies, only how to generate them. With regards to generation, there is basically no change - we still disallow programmers to set cookie names that are not a 'token', as defined by section 4 of that document, which is the same as RFC 2109 in terms of valid cookie names if you look at it. It is not obvious to me that Python's BaseCookie implementation obeys RFC 2109 (due to the way character lists are defined in the opposite way), but if you believe the comments in the module then it does. I haven't read the rest of RFC 6265 and checked BaseCookie against it - that would be a much bigger job. But with respect to the change in my patch, it looks like we are all OK. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2193 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Luke Plant l.plant...@cantab.net added the comment:
@ David Murray:
Thanks for taking the time to look at this - can I trouble you to keep going
and read my response?
Thanks.
You wrote:
IMO the thing that needs to be fixed here is that receiving an invalid cookie
makes it difficult to receive the valid cookies.
I agree absolutely, and my patch implements exactly that aim. So I don't
understand why the rest of your reply goes on to assume a very different goal -
handling RFC-invalid cookies such that we can read their values.
I'd love to accept your patch, but silently ignore sounds like a bad
idea and is something we try to avoid in Python where practical.
silently ignore is what the current BaseCookie implementation does for
**every other** type of invalid input, with the only exception (I can find)
being the case where everything is correct apart from the name:
from Cookie import SimpleCookie
c = SimpleCookie()
c.load('rubbish')
c
SimpleCookie:
c.output()
''
c.load('more:rubbish')
c
SimpleCookie:
c.load('name=value')
c
SimpleCookie: name='value'
c.load('name=value; invalidattribute;')
c.output()
'Set-Cookie: name=value'
c.load('xyz123sfs;;=-abc')
c
SimpleCookie: name='value'
c.load('namewith:colon=value')
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python2.7/Cookie.py, line 632, in load
self.__ParseString(rawdata)
File /usr/lib/python2.7/Cookie.py, line 665, in __ParseString
self.__set(K, rval, cval)
File /usr/lib/python2.7/Cookie.py, line 585, in __set
M.set(key, real_value, coded_value)
File /usr/lib/python2.7/Cookie.py, line 460, in set
raise CookieError(Illegal key value: %s % key)
Cookie.CookieError: Illegal key value: namewith:colon
As you said, I think this ticket is about fixing that last one, which is the
gross exception to the rule, and the only thing that is causing major problems
for people.
I agree that handling cookies with invalid names so that we can read them would
be nice, but I think it is **very** difficult to find a rationale for saying
that this bug fix should have to wait for that change.
In addition, I do not think there is any sensible way to implement that
suggestion given the API of BaseCookie at the moment - it's not just the
implementation I baulked at, it is the API of BaseCookie that works against you
every step of the way.
The API of BaseCookie works like this in the typical case:
Consuming:
input - load()- store in BaseCookie - __getitem__()
Generating:
input - __setitem__() - store in BaseCookie - output()
(Of course you don't have to do it that way, but looking at the docs and
examples, http://docs.python.org/library/cookie.html, it's very clear that it's
meant to be used that way).
The fact that both modes involves storing in BaseCookie really messes up any
attempt to make these two work differently, and means you would have a really
surprising and strange API whichever way you do it.
So, option (1): you could allow BaseCookie to store invalid cookie names if
they come via load, but not via __setitem__(). This means that you've got an
easy work-around for BaseCookie refusing to store your value - just use
'load()' instead. It also means that simple code like this fails:
c['name:val'] = c['name:val']
which can be a problem if you are trying to do some generalised processing of
the contents of a BaseCookie.
This leads us to option (2): allow RFC-invalid cookies to be stored, but then
quietly sanitise (i.e. discard) in output().
But this becomes a much worse example of silently ignoring - the former is
tolerant handling of data that is outside the programmers control - Postel's
law. But this would be accepting incorrect data from a programmer, and then
silently discarding it, is what we should do our utmost to avoid.
Neither of these options is any good, and it is because the API of BaseCookie
was just not designed for it. The only sensible things to do, given our API, is
sanitise on input. We could have an 'RFC-invalid' mode, but it would have to be
turned on for the whole Cookie instance, and it would be a feature addition. An
alternative implementation would be a 'badmorsels' attribute which preserves
the rubbish where possible, in case you want it - but again, it's a feature
addition.
Finally, I think the behaviour you are aiming at is unreasonable to ask for,
especially in this ticket. You are essentially asking for a tolerant kind of
cookie parsing which does its best to do 'do-what-I-mean'. But:
1) You haven't specified further than that (and there are no RFCs of use)
2) in general that kind of thing is notoriously hard to get right
3) the job is never finished - there are always more cases of invalid cookies
that you *could* handle
4) and in fact it is impossible to provide an implementation that pleases
everyone - there will always be invalid cookies that were 'meant' to be one
thing, but the implementation
[issue11001] Various obvious errors in cookies documentation
New submission from Luke Plant l.plant...@cantab.net: Docs for SimpleCookie, BaseCookie.value_encode and BaseCookie.value_decode are obviously incorrect. Attempt at patch attached. The error has existed in every Python version I've seen, I've tagged the ones I believe can receive fixes, sorry if I've made a mistake. Thanks. -- assignee: docs@python components: Documentation files: http_cookies_doc_corrections.diff keywords: patch messages: 126962 nosy: docs@python, spookylukey priority: normal severity: normal status: open title: Various obvious errors in cookies documentation versions: Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file20507/http_cookies_doc_corrections.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5043] get_msvcr() returns None rather than []
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: i'm really sorry, eric, but the decision to ban me from interacting with python developers for 18 months+ has left me with zero working knowledge of many of these complex issues which i was heavily and actively involved in at the time, and could have answered immediately. the opportunity to interact with me and to move the mingw32 port forward was at the time, not 18+ months later. i've since *removed* the highly complex development environment which was tricky as hell to set up (mingw32 cross compiler, mingw32 native compiler, python, native python, wine, MSYS under wine, python-win32 under wine) because it was declared that the work being carried out was worthless. i'll have to leave it to roumen to answer this one. l. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5043 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment:
I disagree;
i would say that you're entitled to disagree, but i have to point
out that unless you've actually been through the process of trying
to port python to mingw32 you're not really in a position of ...
how can i put this best... you're entitled to say i disagree
but that doesn't actually carry any weight.
if you said i've tried compiling this patch, and i looked at
it and i disagreed with the decision to create a new platform,
so i removed that code, here's an updated patch, i found it to
work absolutely fine THEN i would say that you are in a position
of authority to disagree.
so - question: have you actually _tried_ compiling python with
mingw32, with the latest patch?
programs compiled with mingw32 run on Windows, and use the MSVC
runtime.
they do indeed. this however has absolutely no relevance.
It's the same platform as the current win32 build.
It's even possible to use mingw32 to compile extensions
for the VS9.0 based python.exe.
it is indeed. the patch that i did allowed you to specify
a gcc spec file which did exactly that: i added options to
compile not only extensions but also the entire python.exe
to use a different MSVCRT runtime.
_and_ it did assemblies, too.
A different compiler does not make a new platform.
ok.
unfortunately, as the work that i did was well over a year ago,
i'm going from memory - but basically, i'm very very sorry to
have to point out that you don't know what you're talking about,
here.
let me try and go through it.
look at the platform detection code: it parses the gcc version
string. it goes if compiler has string gcc but also has win32
then it must be cygwin platform.
otherwise it goes this must be MSVC win32 platform.
this _simply_ doesn't work, hence the need to do further
detection, hence the need to have a separate compiler type.
... but it doesn't end there: there are subtle differences
between MSVC win32 and MINGW32 win32 (differences in the
build .lib files that specify what functions are available
in the DLLs. mingw32 is a reverse-engineering project,
remember?)
to be honest i can't remember if i actually set sys.platform to
mingw32 - but the more time i spent getting more and more modules
to compile, the more blindingly obvious it was that a new platform
type was needed.
i encountered dozens of assumptions that if sys.platform == 'win32'
then you MUST be building using visual studio: f*** off with your
attempt to compile this module using gcc.
over the eight to ten week period in which i focussed on this
non-stop for about 13 hours a day, the list just went on and on
of discrepancies that had to be solved, and if i _hadn't_ set a
new platform type, it would have been necessary to add extra
tests instead:
if sys.platform == 'win32' and not {something to detect mingw32}:
mingw32 _really_ does fall between both worlds: not just the
compiler type is different, but there are even features and
functions _missing_ from mingw32 that are present in MSVC.
i had to work with roumen to get patches to mingw32 upstream
in some cases!
so please _do_ stop putting road-blocks in the way. this is
a complex enough project, having to fit half way between
two disparate worlds, without it being stymied by disagreement
when you haven't _actually_ tried compiling this code (if you
have, i apologise).
btw if you'd like to try compiling it, but are adamant about
staying away from proprietary operating systems, i _did_
manage to get python 2.5 and 2.6 cross-compiled to run under wine.
ironically there were long-standing bugs in wine that ended up
getting fixed as a result of running the 25,000 python unit tests,
but that's another story... :)
l.
p.s. msys runs under wine as well, but the configure stage takes
well over an hour. the patch i created cut out most of configure
and replaced it with a pcconfig.h just like win32, which i had
to create by hand. this was quicker than waiting for configure
to run.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3871
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: perhaps, amaury, you might like to, instead of saying i disagree, you might like instead to say something like this: that sounds... interesting, and a little scary - creating an entirely new platform! are you absolutely sure it's necessary?? could you please perhaps elaborate and give a good justification behind why that decision was taken? you see how radically different that is? on the one hand you're telling three volunteers who have spent considerable time and resources - unpaid - on improving python's reach that they are, to put it bluntly, complete ignorant f*g morons, and on the other you're engaging with them, encouraging them, and generally trusting them. i'm really sorry: i really don't like having to be the one to point these kinds of things out, but... you see what i'm saying? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: I am not sure how we should do this, but here's my proposal for distutils2 at least: - make this new feature a standalone package that patches distutils - release it for 2.x - let's add your work in distutils2 as well, so it's back in the stdlib in 3.x that would work very well: people doing new setup.py files, converting from python2 etc., will, duh, need to do _some_ conversion: they'll expect breakage and to be using distutils2 anyway. thank you tarek. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: The current patch makes too many changes in core distutils functions; it cannot be accepted in this form. I'm sure that most of the needed changes can be made in a subclass of the present Mingw32CCompiler. that's what i did when creating the _other_ (yet another) mingw32 patch - however _some_ minimal changes to core distutils _are_ unfortunately required. and to sys.py and os.py - this is, after all, a new platform! it starts off with sys.platform == 'mingw32', requiring detection of gcc compiler type BUT and os type of win32, and goes from there. right now, detection logic is: * if gcc on win32 platform, platform MUST be cygwin * if msvc compiler, platform MUST be win32 both of which are... well... wrong! :) so, i found that it was necessary to start in os.py and sys.py, create a platform-type mingw32 and _then_ it was easy to do a MingW32Compiler etc. with (mostly) additions not modifications to distutils, but _necessary_ to add in detection of the type. if distutils was designed to do exec import distutils.compiler.%s as compiler % sys.platform and go from there then this would be an entirely non-issue: no modifications to distutils would be required, just a completely separate module containing the new compiler... ... but distutils isn't designed that way, is it? :) l. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: erik, i'm really sorry, but the freeze on distutils simply cannot be accepted: there really is no other way, as you can see from the previous walkthrough analysis, and is reinforced by the further analysis below. simply put: if the freeze on distutils is not lifted, then this entire set of work, which has been going on for years and _precedes_ the distutils freeze by at least 18 months, is completely, utterly and totally wasted. let's walk through the situation where distutils2 is forced to be used. what you're asking for is, basically, that every single third party package, of which there must be tens of thousands, must be patched for compilation on mingw32... _just_ so that it says if sys.platform == 'mingw32': from distutils2.core import setup else: from distutils.core import setup, is that correct? does that strike you as being completely and utterly unreasonable an expectation, to ask third parties to modify setup.py scripts which have worked perfectly well for years, many of which are likely to no longer even have a maintainer? that leaves patching - which should be nothing more than _adding_ to - not changing existing compilers - ADDING an extra compiler - distutils as the only option. now, that can be done monkey-patch style (i.e. at runtime, by adding in code very early on in python startup, or perhaps by patching the import system to replace the word distutils with distutilsmingw32) or it can be done... by lifting the distutils freeze. perhaps i should ask: what _exactly_ is the problem, and why do several teams complete and utter failure to do the correct thing by making changes to _existing_ compile platforms have anything to do with _this_ team's patches which add a new totally separate platform that has absolutely nothing to do with any of the other platforms? i could say more, but i believe the point is clear: none of the people involved in seeing mingw32 added as a platform had _anything_ to do with the past failures, so why punish and mis-trust the python-mingw32 for other peoples' failures? -- nosy: +lkcl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3781 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: NUTS. many apologies: my comments should have gone to issue 3871 not 3781. arse! is it possible to delete comments? :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3781 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: erik, i'm really sorry, but the freeze on distutils simply cannot be accepted: there really is no other way, as you can see from the previous walkthrough analysis, and is reinforced by the further analysis below. simply put: if the freeze on distutils is not lifted, then this entire set of work, which has been going on for years and _precedes_ the distutils freeze by at least 18 months, is completely, utterly and totally wasted. let's walk through the situation where distutils2 is forced to be used. what you're asking for is, basically, that every single third party package, of which there must be tens of thousands, must be patched for compilation on mingw32... _just_ so that it says if sys.platform == 'mingw32': from distutils2.core import setup else: from distutils.core import setup, is that correct? does that strike you as being completely and utterly unreasonable an expectation, to ask third parties to modify setup.py scripts which have worked perfectly well for years, many of which are likely to no longer even have a maintainer? that leaves patching - which should be nothing more than _adding_ to - not changing existing compilers - ADDING an extra compiler - distutils as the only option. now, that can be done monkey-patch style (i.e. at runtime, by adding in code very early on in python startup, or perhaps by patching the import system to replace the word distutils with distutilsmingw32) or it can be done... by lifting the distutils freeze. perhaps i should ask: what _exactly_ is the problem, and why do several teams complete and utter failure to do the correct thing by making changes to _existing_ compile platforms have anything to do with _this_ team's patches which add a new totally separate platform that has absolutely nothing to do with any of the other platforms? i could say more, but i believe the point is clear: none of the people involved in seeing mingw32 added as a platform had _anything_ to do with the past failures, so why punish and mis-trust the python-mingw32 for other peoples' failures? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: I'm trying to read the patch. It contains many interesting things (and others I have no opinon about), but it is very large, and makes it difficult to comment or find why some change were made etc. amaury: unfortunately, the development on adding mingw32 as a platform has been ongoing for well over three years, with absolute silence and rejection of its existence. it was only when a fourth person showed interest in it (LRN) that it became accepted - but that was... only two months ago! basically, this situation should never have been allowed to get this far: the very first patch that was created, three nearly four years ago, should have been accepted, and then an incremental process could have been taken, _and_ the silly situation in which distutils gets frozen during the time when people have been completely ignoring this ongoing work would never have occurred. but, that's the situation: the bed has been made, and now developers have to lie in it. sorry to be the one that's pointing this out, but... anyway. your idea to split this into a series has merit: personally i much prefer git, because of git-format-patch, but i have to say i've never done patch regeneration based on a review / change-patch-in-middle-of-series / regenerate git-format-patch cycle. should be fun! :) but the very very first thing that has to happen - before any of this work is begun - is for the distutils freeze to be lifted, or for someone to come up with a _sensible_ alternative solution. if that cannot be done, then roumen and LRN won't _stop_ working on python-mingw32: the end result will be that they just... continue to create a single patch file that will just get larger and larger. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10148] st_mtime differs after shutil.copy2
New submission from Luke McCarthy l...@iogopro.co.uk: When copying a file with shutil.copy2() between two ext4 filesystems on 64-bit Linux, the mtime of the destination file is different after the copy. It appears as if the resolution is slightly different, so the mtime is truncated slightly. For example: source file mtime: 1287367331.8433506 destination file mtime: 1287367331.84335 -- components: Library (Lib) messages: 119176 nosy: shaurz priority: normal severity: normal status: open title: st_mtime differs after shutil.copy2 type: behavior versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10148 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9824] SimpleCookie should escape commas and semi-colons
New submission from Luke Plant l.plant...@cantab.net: In developing Django, we found that some browsers don't treat commas and semi-colons in cookie values (i.e. the Set-Cookie header) the way that RFC 2109 says they should. (Safari splits the header on a comma followed by space, Internet Explorer splits on semi-colons - both irrespective of any 'quoting'). The result is that if you use SimpleCookie to create Set-Cookie headers, where the cookie value contains a comma or semi-colon, you can get all kinds of breakage. In the end, we realised that the RFCs are kind of irrelevant, and we have to look at what browsers actually do. So, it would be much more useful if semi-colons and commas were escaped the way that other characters are by SimpleCookie. Our discussion/findings are here: http://code.djangoproject.com/ticket/12470#comment:4 http://groups.google.com/group/django-developers/msg/2cb729938e8e67ca The patch to Cookie.py (Python 2.X) or http/cookies.py (Python 3.X) is simple and follows. I'm assuming that this applies to Python 3.2 and 3.3, but I haven't checked. -- components: Library (Lib) files: simplecookie_fix.diff keywords: patch messages: 116030 nosy: spookylukey priority: normal severity: normal status: open title: SimpleCookie should escape commas and semi-colons type: behavior versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file18833/simplecookie_fix.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9824 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9824] SimpleCookie should escape commas and semi-colons
Luke Plant l.plant...@cantab.net added the comment: I forgot to mention backwards compatibility: In the context of Cookie being used in a web application, if developers were relying on literal commas and semi-colons being present in the client side cookie value (e.g. in javascript), the patch will introduce an incompatibility. A quick review of cookies on my computer shows that 22 out of 3079 have commas in them, and none have semi-colons in them. For those with commas, there would still only be a problem if they were reading them client side, or not using Python's Cookie library to decode the values server side. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9824 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: sorry to have to ask, but could we get some feedback please so that this issue may move forward? currently there is a conflict between what is required and what is stated as being absolute law. let's imagine that it is reasonable to expect distutils2 to be used. python proceeds with the mingw32 patches using distutils2, python 2.N is compiled and released. an average user installs python 2.N mingw32 and they run python setup.py install on a package - what happens? they get a compile error, don't they? why do they get a compile error? because the setup.py tries to build some c code, and at the top of *their* setup.py is import distutils. so you now force thousands of developers to patch a their setup.py scripts - scripts which have worked for years - _just_ so that those packages can cope with the use of distutils2 for the mingw32 platform? so we have another reducto ad absurdum which demonstrates that it is impractical to expect distutils to be frozen. thus, we are forced to consider alternative options, such as monkey-patching of distutils, to satisfy the requirements. would the following be acceptable, to be inserted somewhere in the path so that it is guaranteed to work at all times? import mingw32_distutils_compiler import sys if distutils.compiler in sys.modules: sys.modules['distutils.compiler'] = mingw32_distutils_compiler where mingw32_distutils_compiler performs an import of distutils.compiler and performs a monkey-patch mish-mash to combine and replace various parts of the compiler module at run-time, to get round the freeze objections. would that be acceptable? please say no, because the long-term viability and maintainability of such practices is virtually nil. basically i'm pointing out to you, eric, that the freeze on distutils is unworkable and impractical and unnecessary. this isn't bug-fixing of distutils, it's absolutely necessary and critically required because this is an entirely new platform. * it's not cygwin: cygwin uses standard gcc but with weird outputs and quirks. * it's not standard unix gcc: you need to output .dll not .so * it's not msvc: mingw32-gcc doesn't accept /this /that for options. therefore i'm very sorry to have to spell it out but a new compiler and linker type - a NEW compiler and linker type - an ADDITIONAL compiler and linker type - IS required in order to cater for this platform, and there's no getting away from that fact. please could we have some acknowledgement of this fact, and acceptance of this fact, and a plan for moving forward with careful review of this patch, so that LRN and others do not have their time spent pursuing a direction involving distutils2 which will be completely fruitless? many many thanks, l. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: On Sun, Aug 8, 2010 at 12:27 AM, Éric Araujo rep...@bugs.python.org wrote: Éric Araujo mer...@netwok.org added the comment: FYI, distutils is frozen because even minor bug fixes have broken third-party tools in the past, that’s why new features and bug fixes land in distutils2. Only some bug fixes that are sure not to break things make their way into distutils. distutils2 will be reintegrated into the stdlib in 3.2 or 3.3, but standalone releases will be made for Python 2.4 up to 2.7 and 3.x. eric, it's been a year since i did the mingw32 port so i'll try to recall what it was that i did, but i have recollections of also having to add to distutils, specifically adding an extra compiler class and an extra linker class, derived from cygwin i believe (and then adding, obviously, platform detection logic and options to make use of them). using logic analysis on the conditions, it can be shown that there is nothing that can satisfy the conditions (one of which is distutils is frozen, another is distutils will not go into python2.N or 3.x etc). thus, something has to give. detailed analysis and recommendations follow: if distutils2 is to be standalone it literally makes it impossible to build python 2.4 up to 2.7 and 3.x using mingw32, because the build infrastructure will be entirely missing. how can you build python 2.7 using mingw32 if one of the critical dependencies - actually saying use mingw32 - is missing?!! the decision to keep distutils frozen therefore forces the mingw32 developers to create a special version of distutils, one which has to be added as a patch to python - let's call it distutils_mingw32 - which has the exact same functionality as distutils except that it is extended to have a mingw32 compiler and linker class. adding such a patch (which adds a copy of distutils called distutils_mingw32) would be extremely disruptive, as it would defeat the entire purpose of distutils, and i would be extremely surprised if it was accepted. so, unpalatable-as-defined-by-previous-negative-experience as it may be, the only sensible option is to do an extremely careful and thorough review of LRN's distutils compiler and linker class additions, and ensure that they are _purely_ additional classes, even at the expense of duplicated code. please remember that mingw32 is an _additional_ platform, not a change to any _existing_ platforms. l. p.s. the only other option i can think of would be to add in build-time options where you can specify the fully-qualified path to where distutils2 can be found. this would be somewhat... contrived, but would work. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8374] Some locales are unsupported
New submission from Luke Jennings ubuntujenk...@googlemail.com: In the locale module there are some locales that are not supported these the ones that I am aware of are nl_AW, sr_RS sr_ME. This information was due to a project that captures screenshots in different languages and we have to retrieve the language code. Related to the origin of the bug https://bugs.edge.launchpad.net/quickshot/+bug/554861 . If any more information is required please let me know. -- components: Extension Modules messages: 102891 nosy: ubuntujenkins severity: normal status: open title: Some locales are unsupported type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8374 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8374] Some locales are unsupported
Luke Jennings ubuntujenk...@googlemail.com added the comment: Other programs do work with the local. I am working on dealing with exceptions, I am rather new to programing and thought it would also be good to try and get this fixed in the original module. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8374 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8374] Some locales are unsupported
Luke Jennings ubuntujenk...@googlemail.com added the comment: Sorry for the confusion but that bug report has two very similar problems to it if you look at https://bugs.edge.launchpad.net/quickshot/+bug/554861/comments/7 and https://bugs.edge.launchpad.net/quickshot/+bug/554861/comments/6 . I think that is calling the locale module. I apologize if i have put this down to the wrong thing I am new to python. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8374 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6534] os.makedirs returns EACCES for C:\
New submission from Luke-Jr luke...@users.sourceforge.net: Should return EEXIST or EISDIR provided C:\ actually exists -- components: Windows messages: 90764 nosy: luke-jr severity: normal status: open title: os.makedirs returns EACCES for C:\ type: behavior versions: Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6534 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6534] os.makedirs returns EACCES for C:\
Luke-Jr luke...@users.sourceforge.net added the comment: At least fix the documentation, then... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6534 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: On Mon, Feb 2, 2009 at 9:10 PM, Roumen Petrov rep...@bugs.python.org wrote: Roumen Petrov bugtr...@roumenpetrov.info added the comment: The proposed patch for this issue include parts of other pending issues - so its all is single file. If python team don't like idea for canonical host names (part of issue 3754) this patch can be modified do not use host-triplet. Also some discussions in py-dev list show that small patches are preferred. I'm ready to split into small patches to be reviewed. excellent. that _would_ be good. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5051] test_update2 in test_os.py invalid due to os.environ.clear() followed by reliance on environ COMSPEC
New submission from Luke Kenneth Casson Leighton l...@lkcl.net:
class EnvironTests(mapping_tests.BasicTestMappingProtocol):
check that os.environ object conform to mapping protocol
type2test = None
def _reference(self):
return {KEY1:VALUE1, KEY2:VALUE2, KEY3:VALUE3}
def _empty_mapping(self):
vv
os.environ.clear() -- ***
^^
return os.environ
def setUp(self):
self.__save = dict(os.environ)
os.environ.clear()
def tearDown(self):
os.environ.clear()
os.environ.update(self.__save)
# Bug 1110478
def test_update2(self):
if os.path.exists(/bin/sh):
os.environ.update(HELLO=World)
v
value = os.popen(/bin/sh -c 'echo $HELLO').read().strip()
^ finds os.environ['COMSPEC'] to be empty!
self.assertEquals(value, World)
this test will obviously fail, see _PyPopenCreateProcess in
posixmodule.c.
if (i = GetEnvironmentVariable(COMSPEC,NULL,0)) {
char *comshell;
}
/* Could be an else here to try cmd.exe / command.com in the path
Now we'll just error out.. */
else {
PyErr_SetString(PyExc_RuntimeError,
Cannot locate a COMSPEC environment variable to
use as the shell);
return FALSE;
}
the environment variables having been destroyed, there _is_ no
COMSPEC to obtain a working cmd.exe or command.com in order to
execute the /bin/sh (or /bin/sh.exe in the case of having installed
msys and created a symlink from c:/msys/bin to c:/bin).
--
components: Tests
messages: 80502
nosy: lkcl
severity: normal
status: open
title: test_update2 in test_os.py invalid due to os.environ.clear() followed by
reliance on environ COMSPEC
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5051
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5056] PyAPI assumes OS can access shared data in loadable modules (windows can't)
New submission from Luke Kenneth Casson Leighton l...@lkcl.net:
an assumption has been made in the python core api that all operating
systems dynamic module loading can access data segments. windows
_cannot_ do this.
the workaround has been to statically link absolutely _everything_
into a single whopping great dll.
the proper solution is to provide accesser functions:
PyAPI_FUNC(PyObject *)
PyErr_GetPyExc_OSError(void)
{
return (PyObject*)PyExc_OSError;
}
PyAPI_FUNC(char*) _PyStructSequence_Get_UnnamedField(void)
{
return PyStructSequence_UnnamedField;
}
... actually the _best_ solution is to have everything that's needed in
a vector-table [discussed on python-dev mailing list]
--
components: Build
messages: 80513
nosy: lkcl
severity: normal
status: open
title: PyAPI assumes OS can access shared data in loadable modules (windows
can't)
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5056
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5058] stop pgen.exe from generating CRLF-ended files and causing mayhem with win32-based patch submissions
New submission from Luke Kenneth Casson Leighton l...@lkcl.net:
diff --git a/Parser/pgenmain.c b/Parser/pgenmain.c
index fc27a2c..a4d4911 100644
--- a/Parser/pgenmain.c
+++ b/Parser/pgenmain.c
@@ -49,7 +49,7 @@ main(int argc, char **argv)
graminit_h = argv[2];
graminit_c = argv[3];
g = getgrammar(filename);
- fp = fopen(graminit_c, w);
+ fp = fopen(graminit_c, wb);
if (fp == NULL) {
perror(graminit_c);
Py_Exit(1);
@@ -58,7 +58,7 @@ main(int argc, char **argv)
printf(Writing %s ...\n, graminit_c);
printgrammar(g, fp);
fclose(fp);
- fp = fopen(graminit_h, w);
+ fp = fopen(graminit_h, wb);
if (fp == NULL) {
perror(graminit_h);
Py_Exit(1);
@@ -79,7 +79,7 @@ getgrammar(char *filename)
grammar *g0, *g;
perrdetail err;
- fp = fopen(filename, r);
+ fp = fopen(filename, rb);
if (fp == NULL) {
perror(filename);
Py_Exit(1);
--
components: Build
messages: 80517
nosy: lkcl
severity: normal
status: open
title: stop pgen.exe from generating CRLF-ended files and causing mayhem with
win32-based patch submissions
type: feature request
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5058
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5056] PyAPI assumes OS can access shared data in loadable modules (windows can't)
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: apologies - case of mistaken identity! patch attached - beginnings of moving data over to accessor-functions. attached here because it is relevant for vector-table future work. please close this bug. -- keywords: +patch Added file: http://bugs.python.org/file12855/data_into_fns.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5056 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5043] get_msvcr() returns None rather than []
New submission from Luke Kenneth Casson Leighton l...@lkcl.net:
def get_msvcr():
Include the appropriate MSVC runtime library if Python was built
with MSVC 7.0 or later.
msc_pos = sys.version.find('MSC v.')
if msc_pos != -1:
msc_ver = sys.version[msc_pos+6:msc_pos+10]
if msc_ver == '1300':
# MSVC 7.0
return ['msvcr70']
elif msc_ver == '1310':
# MSVC 7.1
return ['msvcr71']
elif msc_ver == '1400':
# VS2005 / MSVC 8.0
return ['msvcr80']
elif msc_ver == '1500':
# VS2008 / MSVC 9.0
return ['msvcr90']
else:
raise ValueError(Unknown MS Compiler version %i % msc_Ver)
return [] -
--
components: Build
messages: 80466
nosy: lkcl
severity: normal
status: open
title: get_msvcr() returns None rather than []
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5043
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5046] native win32 and wine mingw+msys build of python2.7
New submission from Luke Kenneth Casson Leighton l...@lkcl.net: this is an update of the mingw+msys port for native win32, with the aim of being both compiled and used under both wine-win32 and native-win32. it is not a cross-compile patch. it does not require -lwine. it does not require a unix system. it does not require cygwin. (repeat the previous four sentences for both build _and_ use of the resultant python.exe). this information is specifically given and stated [so blandly] because several people have been extremely confused by what this patch achieves, due to the tools being utilised to achieve it [wine]. the patch is against svn trunk r68884. as of 2 hours ago, the following tests failed: 22 tests failed: test_cmath test_cmd_line_script test_compiler test_ctypes test_decimal test_distutils test_file test_logging test_mailbox test_math test_ntpath test_os test_parser test_posixpath test_pwd test_smtplib test_startfile test_tempfile test_transformer test_winsound test_zipfile test_zipimport_support since then, several have been corrected. test_pwd should not be being tested. several of the tests (test_tempfile) are fails due to use of native wine msvcrt (it gets better when win32 msvcrt is used). this is work-in-progress for those people interested. builds with --enable-msvcr9build are possible. incorporation of roumen's cross-compile work is ongoing. -- components: Build files: python-2.7a0-r68884-mingw-msys.patch keywords: patch messages: 80481 nosy: lkcl severity: normal status: open title: native win32 and wine mingw+msys build of python2.7 type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file12849/python-2.7a0-r68884-mingw-msys.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5046 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: updated. incorporating roumen's work as well. Added file: http://bugs.python.org/file12826/f ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5026] [reopening] native build of python win32 using msys under wine.
New submission from Luke Kenneth Casson Leighton l...@lkcl.net: reopening a new bug with the exact same title due to #4954 having been unilaterally closed without discussion, nor reasons specified. simple courtesy would dictate that some sort of dialog is entered into especially when someone is putting in significant amounts of work in developing python, and has plans to forward-port the patch to python2.6 and trunk, merge it with #3844 and much more. -- components: Build files: f messages: 80339 nosy: lkcl severity: normal status: open title: [reopening] native build of python win32 using msys under wine. versions: Python 2.5 Added file: http://bugs.python.org/file12827/f ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5026 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5026] [reopening] native build of python win32 using msys under both wine and native win32
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: so. let me be clear. this bug is a continuation of work to port python to mingw, with a specific BUT NOT UNIQUE focus of ensuring that python can be compiled under wine. THE ATTACHED PATCH CAN ALSO BE USED TO COMPILE PYTHON UNDER WIN32. -- title: [reopening] native build of python win32 using msys under wine. - [reopening] native build of python win32 using msys under both wine and native win32 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5026 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5026] [reopening] native build of python win32 using msys under both wine and native win32
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: attached also manifests and rc files for building on msvcr80 Added file: http://bugs.python.org/file12829/x ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5026 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: manifests and rc files for msvcr80 build Added file: http://bugs.python.org/file12830/x ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: martin, so sorry, i didn't see your comments - no dang hell no i'm not done yet. regarding graminit.h: graminit.h isn't being removed - i keep editing it out of the patch. i'm not _submitting_ it as part of the patch because what happens is that Parser/pgen.exe generates CRLF and EERY single line of graminit.h gets replaced. so it's a bit irritating to keep having to even see it, so i removed it from my local repository. if i accidentally submit its removal please ignore it, entirely. people _are_ tracking the progress of this development, and assisting in the work. i'm using the bugtracker to communicate the progress. closing the bug looks... like... i dunno - it's not very helpful, though, i have to say. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5026] [reopening] native build of python win32 using msys under both wine and native win32
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: martin - apologies for shouting: i hadn't seen your explanations of why #4954 was closed. i'm not happy that it _was_ closed, but that's another story. yes of course i will be going on to python2.6 and up - first though is to focus on python2.5 and get _that_ into shape, then moving on to 2.6 and 2.7 is easy. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5026 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5010] repoened test_maxint64 fails on 32-bit systems due to assumption that 64-bit fits into long due to it being closed without asking me whether there was anything else involved
New submission from Luke Kenneth Casson Leighton l...@lkcl.net: this is reopening http://bugs.python.org/issue4977 because it was closed without asking whether there was any further information or anything else that required investigation. there is no way for me to reopen the bug so i am forced to open a new one. mark - don't do that again, please. the suggestion to use PyOS_strtol was a good one: you should have left the bug as-is after that suggestion, and WAITED until i had tested that. the bug involves 64-bit zip files. the fact that a 32-bit int is being returned, as -4932893211 (whatever) instead of 44951 (whatever) is causing the problem. so will you be kind enough and courteous enough to wait until i have provided full information and investigated this issue? or do you not want me to bother? -- components: Build messages: 80241 nosy: lkcl, marketdickinson severity: normal status: open title: repoened test_maxint64 fails on 32-bit systems due to assumption that 64-bit fits into long due to it being closed without asking me whether there was anything else involved versions: Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5010 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4977] test_maxint64 fails on 32-bit systems due to assumption that 64-bit fits into long
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: hiya folks, lots of comments here. in no particular order: 1) thanks for reopening the bug 2) apologies for not being clearer - it's Lib/test/test_testzip.py specifically the TestZip64InSmallFiles case that's failing. 3) it's not yet _clear_ whether strtol is the cause of the problem - i haven't yet got round to testing that because i'm in the middle of a rebuild trying to get msvcr80 assemblies to work, and i'll need to back out of that and rebuild with msvcrt or msvcrt71 first. 4) i'm not yet certain as to whether it's the mingw 3.4.5 _compiler_ that's broken (!) there's some empirical evidence suggesting that it might well be, but again, that's not yet determined 5) under wine, strtol goes through to msvcrt, which goes through to ntdll, which goes through to the _unix_ system's strtol. wine is compiled with -m32, so it _should_ still all be doing 32-bit stuff, even though i'm using a 64-bit host (debian/amd64). on balance, i'd very much appreciate this being kept open so that i can keep track of determining what the heck is going on - i have about five or six different things to investigate. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4977 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: roumen, hi, can you add: BASECFLAGS=-mthreads $BASECFLAGS LDFLAGS=-mthreads $LDFLAGS when compiling with threads, and... a second request: _block_ people from compiling without mthreads, because there's a bug in wine's msvcrt _filbuf routine where it doesn't perform CRLF (at all) and it should. http://bugs.winehq.org/show_bug.cgi?id=16970 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: roumen, hi, can you add: BASECFLAGS=-mthreads $BASECFLAGS LDFLAGS=-mthreads $LDFLAGS when compiling with threads, and... a second request: _block_ people from compiling without mthreads, because there's a bug in wine's msvcrt _filbuf routine where it doesn't perform CRLF (at all) and it should. http://bugs.winehq.org/show_bug.cgi?id=16970 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: workarounds for a couple of wine bugs, also includes e.g. #4977 64-bit assumptions on 32-bit systems. Added file: http://bugs.python.org/file12780/f ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Changes by Luke Kenneth Casson Leighton l...@lkcl.net: Removed file: http://bugs.python.org/file12764/x ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4956] Py_Initialize needs to be done before file load (on msys+wine)
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: hi gabriel, thanks for looking at this, and my apologies for not editing the patch to remove debug and other information: i'm in the middle of a comprehensive porting session. WEIRD_DEBUG was me endeavouring to find out what the hell is going on test_str.py segfaulted python under wine due to HAVE_SNPRINTF not being defined - but that's irrelevant to this issue likewise ignore the modification to setup.py regarding the advice to seek out and understand the cause, i have to say that i much prefer to ... how can i put this best... @BEGIN CAVEAT THE FOLLOWING STATEMENTS ARE MADE WITH ABSOLUTELY NO INTENTION TO CAUSE OFFENSE DO NOT TAKE THIS PERSONALLY IN ANY WAY DO NOT TAKE IT AS A DELIBERATE INTENT TO OFFEND, CAUSE OFFENSE, CRITICISE OR OTHERWISE INDICATE MALICIOUS OR HOSTILE INTENT being absolutely honest: i genuinely do not care about the cause. what i care about is working. does it work if this code is moved? yes. does it work if the code is not moved? no. does it _matter_ if the cause is identified? no. will someone else, possibly in the future, accidentally encounter or deliberately and actively seek out the cause? possibly. so - many many apologies for saying this, but i have much better and more interesting and valuable things to be doing with my time than _finding out_ why moving specific bits of code makes things works. yes it would be nice to know... but i don't care!! because, most importantly, me _knowing_ makes absolutely -all difference to the outcome of whether it will work or not. so, on balance, i'd rather spend my time finding out the additional code-moving and code-improving required to debug the additional bug where python.exe -i will give me a prompt but python.exe with no arguments will not (and hangs). @END CAVEAT gabriel, hi, debugging python.exe under msys under wine under linux is _really_ tricky. * gdb.exe under msys under wine under linux not only segfaults on exit but also refuses to fork() in order to spawn the process to be debugged! * strace obviously cannot be used _inside_ msys / wine * strace _outside_ - on the /usr/bin/wine process - often interferes with the processes it is tracking, causing them to run out of resources and also to fail to start up. * gdb cannot be attached from _outside_ of wine (/usr/bin/winegdb) to an internal process. fortunately, segfaults inside wine result in quite a good stacktrace report, including line numbers and filenames inside python, but in this case it's hanging - and there's something _really_ weird going on with the stdin, stdout and stderr. overall, then, the payoff in time invested in understanding what is going on by using non-standard and laborious debugging techniques is extremely small. small enough so that, i am very very sorry to say, i'm not going to put any further time into this _other_ than to _actually_ fix bugs, rather than understand bugs. it's a development technique that has saved me _vast_ amounts of time. i never worry about why - i just get on with it. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4956] Py_Initialize needs to be done before file load (on msys+wine)
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: here's a clue: $ ./python.exe -i Python 2.5.2 (r252:60911, Jan 16 2009, 10:34:33) [gcc] on win32 Type help, copyright, credits or license for more information. exit() close failed: [Errno 0] Success $ ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4956] Py_Initialize needs to be done before file load (on msys+wine)
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: here's another clue: $ ./python.exe stdin_is_interactive: 0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4956] Py_Initialize needs to be done before file load (on msys+wine)
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: here's an updated version, without the cruft. this has a workaround for the problem of stdin being seen as not a tty (!) until _after_ Py_Initialize() is run. Added file: http://bugs.python.org/file12763/x ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: martin, hi, thanks for responding. * graminit and configure were removed because they are built automatically. no project should ever include auto-generated files so i assumed that it would be reasonable to remove them from the python_2.5.2 original git commit that i did, in order to produce the diff. on a build, graminit got _replaced_ with one that had ^M after eery siiingle line. so - if graminit and configure _are_ in the main python source tree, it's a serious mistake that should be rectified _immediately_. ... but i doubt that, and so graminit and configure appearing to be removed can be ignored. * regarding your comment that compiling python under msys under wine is a minority platform, i believe that that is also a serious assumption. the reason why it's a minority platform is because... THERE WASN'T ANY CHOICE. i.e. msys and wine simply have not been good enough - and certainly not _demonstrated_ as being good enough - which this patch shows that they now most definitely are - to _have_ any choice about whether python should be compiled with purely free software tools. instead of depending on some ing proprietary piece of double- operating system _and_ the development IDE it walked in on. sorry about that - just to emphasise how distasteful i find it to be _forced_ to use proprietary software, and i'm not the only person. basically, it should be pretty clear that now that python _can_ be compiled for win32 using an entirely free-software platform, the proprietary build chain should be absolutely dropped like a red-hot stone. ... but regarding minority platform? that's really quite funny and ironic. it was a _non-existent_ platform until about... yesterday :) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
