[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
3.7.6 struggles a bit
When i wrote a program, i tried to open it but it struggles to open. -- https://mail.python.org/mailman/listinfo/python-list
[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
ANN: Bokeh 0.12.2 released
Hi all, On behalf of the Bokeh team, I am pleased to announce the release of version 0.12.1 of Bokeh! This is a minor, incremental update that adds a few new small features and fixes several bugs. Please see the announcement post at: *https://bokeh.github.io/blog/2016/9/6/release-0-12-2/ <https://bokeh.github.io/blog/2016/9/6/release-0-12-2/>* which has much more information as well as live demonstrations. And as always, see the CHANGELOG and Release Notes for full details (which are linked from the post). If you are using Anaconda/miniconda, you can install it with conda: conda install bokeh Alternatively, you can also install it with pip: pip install bokeh Full information including details about how to use and obtain BokehJS are at: http://bokeh.pydata.org/en/0.12.2/docs/installation.html Issues, enhancement requests, and pull requests can be made on the Bokeh Github page: https://github.com/bokeh/bokeh Documentation is available at http://bokeh.pydata.org/en/0.12.2 <http://bokeh.pydata.org/en/0.12.2> There are nearly 200 total contributors to Bokeh and their time and effort are what make Bokeh such an amazing project and community. Thank you again for your contributions. Finally (as always), for questions, technical assistance or if you're interested in contributing, questions can be directed to the Bokeh mailing list: bo...@continuum.io or the Gitter Chat room: https://gitter.im/bokeh/bokeh Best luke canavan -- *Luke Canavan* *Software Developer* -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
[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
Python Advanced Help
Okay, So basically I created a python script around 1 year ago to grab an explain_plan from a Greenplum system (Normal SQL) and change it around and explain each step/section, the thing is, I've came back to the python code and I don't understand anything of what it's doing (the code specifically). The Script does work but I just want to explain each section to myself and understand it a bit more as I've forgot Python. This means putting comments/notes in next to each section to explain it but hidden so it doesn't show up when ran, so using the # commenting out #. The aim of the script is to make the explain_plan understandable because it comes out all garbled, so i've turned it upside down because thats how you read it, it goes from bottom to top instead of the default top to bottom. I've put step 1/2 in etc... but I want to know in the code what does what and where etc so I can then expand on the explanation of the explain_plan. Code (Python) - http://pastebin.com/sVhW34fc (This is the one I'm trying to understand) Before & After of an Explain_Plan in SQL Greenplum - http://pastebin.com/81kNWVcy What we're aiming for (Teradatas Explain_Plan) - http://pastebin.com/Nm4g12B3 Regards, Luke Charlton Technical Consultant [cid:4BEA1319-4F97-4ED8-96FE-1A3EDF7DEC22] lcharl...@vldbsolutions.com<mailto:lcharl...@vldbsolutions.com> Mobile : +44 (0) 773 431 3140 -- https://mail.python.org/mailman/listinfo/python-list
[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
Python Requirements
Dear Python-List As part of my A2 Computing coursework, I need to program a solution using Python 3.4. I also need to document the minimum requirements to run Python 3.4 on a Windows machine, including minimum RAM, minimum processing power, minimum hard disk space and monitor resolution. I have searched the Python forums and website, but I was unable to find these requirements. Could you please send me a copy of these requirements for use in my coursework? Thank you for your response in advance, Luke Harrison A2 Computing Student -- https://mail.python.org/mailman/listinfo/python-list
[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
__pycache__
I am in school and there is a problem with my code: When I try to run my code in the python code in the python shell it waits about 10 seconds then shows an error that says “IDLE’s subprocess didn’t make connection. Either IDLE can’t start a subprocess or personal firewall software is blocking the connection.” Then when I press OK it just closes. P.S: My code is encrypting and decrypting using an offset factor. -- https://mail.python.org/mailman/listinfo/python-list
Re: Concerning Dictionaries and += in Python 2.x
Thanks Chris / Mr. Angelico / whatever you prefer. I attempted to post a reply to you before but it could not be viewed even after refreshing several times. You've been helpful. -- https://mail.python.org/mailman/listinfo/python-list
Random ALL CAPS posts on this group
Has anyone noticed these? There have been about three of them recently and they don't seem to have anything to do with Python at all. Does anyone know if there is a good reason they are here? -- https://mail.python.org/mailman/listinfo/python-list
Concerning Dictionaries and += in Python 2.x
I have been having a bit of trouble with the things mentioned in the title. I
have written the following script for a Codecademy course:
stock = {
banana: 6,
apple: 0,
orange: 32,
pear: 15
}
prices = {
banana: 4,
apple: 2,
orange: 1.5,
pear: 3
}
def compute_bill(food):
total = 0
for item in food:
if stock[item] 0:
total += prices[item]
stock[item] = stock[item] - 1
return total
Whenever I run this script, 4 is returned. It does not seem to matter what in
in the list the script is run on. I have tried this on the Codecademy
interpreter/emulator (I'm not sure which they use) and the repl.it interpreter,
but for the same result. If anyone could find the glitch in my code, please let
me know. Thanks!
--
https://mail.python.org/mailman/listinfo/python-list
Re: Concerning Dictionaries and += in Python 2.x
On Monday, January 19, 2015 at 4:21:58 PM UTC-8, Chris Angelico wrote: On Tue, Jan 20, 2015 at 11:12 AM, Luke Tomaneng wrote: def compute_bill(food): total = 0 for item in food: if stock[item] 0: total += prices[item] stock[item] = stock[item] - 1 return total Whenever I run this script, 4 is returned. It does not seem to matter what in in the list the script is run on. I have tried this on the Codecademy interpreter/emulator (I'm not sure which they use) and the repl.it interpreter, but for the same result. If anyone could find the glitch in my code, please let me know. Thanks! In Python, indentation determines block structure. Have another look at this function, and see if you can figure out where the problem is; hint: try printing something out every time you claim a piece of stock. ChrisA Hm. I fixed the indentation like you said, and it worked fine. The only reason I changed the indentation to what you saw in the first place is because Codecademy's Python engine registered an error. However, repl.it accepted the script. I have concluded that the original mistake was actually on the Codecademy site instead of my script. Thanks for helping me out. -- https://mail.python.org/mailman/listinfo/python-list
Program calling unwanted functions
Hello to all those in this forum, My code seems to have a mind of its own. I have been writing a program to reenact the Twenny Wun Vine video, and it seems to be activating functions without me calling them. Here is the script: def kid(): print Cameraman: You stupid. kid1 = raw_input(Kid: ) if kid1.lower() == no im not or kid1.lower() == no i'm not.: print Cameraman: What's nine plus ten? kid2 = raw_input(Kid: ) if kid2.lower() == twenny wun or kid2.lower() == twenty-one or kid2.lower() == twenty one or kid2 == 21 or kid2.lower() == twenny one: print Cameraman: You stupid. Ending program... else: print That is not the right quote. kid() else: print That is not the right quote. kid() def cameraman(): cameraman1 = raw_input(Cameraman: ) if cameraman1.lower() == you stupid: print Kid: No I'm not. cameraman2 = raw_input(Cameraman: ) if cameraman2.lower() == whats 9 + 10 or cameraman2.lower() == whats nine plus ten: print Kid: Twenny wun cameraman3 = raw_input(Cameraman: ) if cameraman3.lower() == you stupid: print Ending program... time.sleep(2) else: print That is not the right quote. cameraman() else: print That is not the right quote. cameraman() else: print That is not the right quote. cameraman() def perspective(): perspective_request = raw_input(Do you want to be the cameraman or the kid? (type the one you want): ) if perspective_request == cameraman: cameraman() if perspective_request == kid: kid() else: print Invalid input. perspective() def instructions(): instructions_request = raw_input(Do you want instructions? (type 'yes' or 'no' without the quotes): ) if instructions_request == no: perspective() if instructions_request == yes: print This is a reenactment of the 'Twenny Wun' Vine. You can type in the empty space to the right of each ':,' then press [return]. Don't use punctuation. perspective() else: print Invalid input. instructions() instructions() The cameraman function restarts itself when it ends, and the kid function calls instructions(). Does anyone know why? -- https://mail.python.org/mailman/listinfo/python-list
How to use the .isalpha() function correctly
Here a very small program that I wrote for Codecademy. When I finished, Codecademy acted like it was correct, but testing of this code revealed otherwise. -- print 'Welcome to the Pig Latin Translator!' # Start coding here! raw_input(Enter a word:) original = str(raw_input) if len(original) 0 and original.isalpha(): print original else: print empty -- No matter what I type in, the result is empty. What do I need to do in order for it to accept words? -- https://mail.python.org/mailman/listinfo/python-list
Re: Run Programming ?????
On Friday, December 12, 2014 4:40:01 AM UTC-8, Delgado Motto wrote: I travel alot, if not just interested in things of pocketable portability, and was curious if you can tell me if Python can be LEARNED from beginner on an IOS device ( with interest of being able to test my code, possibly even if a free website is capable of reviewing scripts ) but if not then I prefer if you can suggest a language that can be used from such a machine. My ultimate goal is to be able to create web pages and internet bots capable of searching specific things for me, simply to save me time in my day as little as crawling Youtube for a song that fails to be uploaded or other related examples. Please advise me. Thanks. Yes, you can learn and write Python on iOS. There are several apps for this. Here are some websites to look at: http://pythonforios.com/ https://itunes.apple.com/us/app/pythonista/id528579881?mt=8 http://kivy.org/#home https://itunes.apple.com/us/app/python-3.2-for-ios/id519319292?mt=8 Codecademy: Code Hour I don't know how well these work, but since there are so many, I am assuming at least a couple are decent. I included Codecademy at the end just in case you need to review some basic syntax, but I'm not sure if you'll need it. Luke Tomaneng -- https://mail.python.org/mailman/listinfo/python-list
Re: Run Programming ?????
On Sunday, December 14, 2014 9:24:54 AM UTC-8, Luke Tomaneng wrote: On Friday, December 12, 2014 4:40:01 AM UTC-8, Delgado Motto wrote: I travel alot, if not just interested in things of pocketable portability, and was curious if you can tell me if Python can be LEARNED from beginner on an IOS device ( with interest of being able to test my code, possibly even if a free website is capable of reviewing scripts ) but if not then I prefer if you can suggest a language that can be used from such a machine. My ultimate goal is to be able to create web pages and internet bots capable of searching specific things for me, simply to save me time in my day as little as crawling Youtube for a song that fails to be uploaded or other related examples. Please advise me. Thanks. Yes, you can learn and write Python on iOS. There are several apps for this. Here are some websites to look at: http://pythonforios.com/ https://itunes.apple.com/us/app/pythonista/id528579881?mt=8 http://kivy.org/#home https://itunes.apple.com/us/app/python-3.2-for-ios/id519319292?mt=8 Codecademy: Code Hour I don't know how well these work, but since there are so many, I am assuming at least a couple are decent. I included Codecademy at the end just in case you need to review some basic syntax, but I'm not sure if you'll need it. Luke Tomaneng Sorry, I didn't include the actual link for Codecademy. Here you go: https://itunes.apple.com/us/app/codecademy-code-hour/id762950096?mt=8 -- https://mail.python.org/mailman/listinfo/python-list
Re: How to use the .isalpha() function correctly
On Sunday, December 14, 2014 9:27:14 AM UTC-8, Chris Warrick wrote: On Sun, Dec 14, 2014 at 6:16 PM, Luke Tomaneng luketoman...@gmail.com wrote: Here a very small program that I wrote for Codecademy. When I finished, Codecademy acted like it was correct, but testing of this code revealed otherwise. -- print 'Welcome to the Pig Latin Translator!' # Start coding here! raw_input(Enter a word:) original = str(raw_input) if len(original) 0 and original.isalpha(): print original else: print empty -- No matter what I type in, the result is empty. What do I need to do in order for it to accept words? -- https://mail.python.org/mailman/listinfo/python-list That's not where the error is, actually. You are: 1. taking input with Enter a word: and NOT SAVING IT 2. setting original to a string representation of the function `raw_input`, which is something like str(raw_input) 'built-in function raw_input' The correct way to do this is: original = raw_input(Enter a word: ) as raw_input already outputs a string. -- Chris Warrick https://chriswarrick.com/ PGP: 5EAAEA16 Thanks very much. I'm not sure how I missed that, since I've used the exact same method you mentioned before. You've been very helpful. -- https://mail.python.org/mailman/listinfo/python-list
[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
decimal numbers
hello, i have been working on a python resistor calculator to let my class show what you can do with python. now i have a script that makes the more speekable value of the resistance (res) #if len(str(res)) 9: # res2 = res / 10 # print de weerstand is %s,%s giga ohms % (res2) #elif len(str(res)) 6: # res2 = res / 100 # print de weerstand is %s,%s Mega ohm % (res2) #elif len(str(res)) 3: # res2 = res / 1000 # print de weerstand is, res2,kilo ohm #elif len(str(res)) 4: # res2 = res # print de weerstand is, res2,ohm i commented it because it doesn't work (yet), when i have a resistance of 9.9 Giga ohms it says it is 9 giga ohms. it seems to work with natural number, anyway of using decimals insted so that it says : the resistance is 9.9 Giga Ohms instead of 9 ? -- https://mail.python.org/mailman/listinfo/python-list
Re: decimal numbers
Op zaterdag 15 februari 2014 10:18:36 UTC+1 schreef Luke Geelen: hello, i have been working on a python resistor calculator to let my class show what you can do with python. now i have a script that makes the more speekable value of the resistance (res) #if len(str(res)) 9: # res2 = res / 10 # print de weerstand is %s,%s giga ohms % (res2) #elif len(str(res)) 6: # res2 = res / 100 # print de weerstand is %s,%s Mega ohm % (res2) #elif len(str(res)) 3: # res2 = res / 1000 # print de weerstand is, res2,kilo ohm #elif len(str(res)) 4: # res2 = res # print de weerstand is, res2,ohm i commented it because it doesn't work (yet), when i have a resistance of 9.9 Giga ohms it says it is 9 giga ohms. it seems to work with natural number, anyway of using decimals insted so that it says : the resistance is 9.9 Giga Ohms instead of 9 ? , wait i have put one %s to much in the print function. this is from a other attempt so please excuse me -- https://mail.python.org/mailman/listinfo/python-list
Re: decimal numbers
Op zaterdag 15 februari 2014 11:04:17 UTC+1 schreef Frank Millman: Luke Geelen luke.gee...@gmail.com wrote in message news:ec88852e-1384-4aa5-834b-85135be94...@googlegroups.com... Op zaterdag 15 februari 2014 10:18:36 UTC+1 schreef Luke Geelen: hello, i have been working on a python resistor calculator to let my class show what you can do with python. now i have a script that makes the more speekable value of the resistance (res) [...] i commented it because it doesn't work (yet), when i have a resistance of 9.9 Giga ohms it says it is 9 giga ohms. it seems to work with natural number, anyway of using decimals insted so that it says : the resistance is 9.9 Giga Ohms instead of 9 ? You don't say which version of python you are using. If you are using python2, an integer divided by an integer always returns an integer - 10/3 3 It was changed in python3 to return a float - 10/3 3.3335 You can reproduce the python3 behaviour in python2 by adding a 'future' directive - from __future__ import division 10/3 3.3335 HTH Frank Millman how (and where) would i add this rule into a script? by import or the calculation? -- https://mail.python.org/mailman/listinfo/python-list
Re: decimal numbers
If i do set form thing in my script i get Invalide syntax pointing at the last word of the form rule -- https://mail.python.org/mailman/listinfo/python-list
Re: decimal numbers
Op zaterdag 15 februari 2014 18:23:20 UTC+1 schreef Ian: On Sat, Feb 15, 2014 at 10:17 AM, Luke Geelen luke.gee...@gmail.com wrote: If i do set form thing in my script i get Invalide syntax pointing at the last word of the form rule Please copy and paste the exact code you ran along with the full text of the exception into your post. Paraphrasing it like this doesn't help us help you. sorry i made a typo its fixed, thanks a lot -- https://mail.python.org/mailman/listinfo/python-list
Re: decimal numbers
Op zaterdag 15 februari 2014 18:42:51 UTC+1 schreef Luke Geelen: Op zaterdag 15 februari 2014 18:23:20 UTC+1 schreef Ian: On Sat, Feb 15, 2014 at 10:17 AM, Luke Geelen luke.gee...@gmail.com wrote: If i do set form thing in my script i get Invalide syntax pointing at the last word of the form rule Please copy and paste the exact code you ran along with the full text of the exception into your post. Paraphrasing it like this doesn't help us help you. sorry i made a typo its fixed, thanks a lot hey, is it possible to remove the .0 if it is a valua without something behind the poit (like 5.0 gets 5 but 9.9 stays 9.9 -- https://mail.python.org/mailman/listinfo/python-list
Re: Flag control variable
Op woensdag 12 februari 2014 06:23:14 UTC+1 schreef Dave Angel: luke.gee...@gmail.com Wrote in message: Can I make it that if C = int(sys.argv[3]) But when I only enter 2 argumentvariable it sets c automaticly to 0 or 1 Why do you ask for 'automatically'? You're the programmer, write the test in the code. if len (sys.argv) == 3: sys.argv. append (0) But of course there are lots of other things you need to check, so consider all of them at the same time. -- DaveA then i keep getting IndexError: list index out of range anyway to prevent it and just set the value to 0? -- https://mail.python.org/mailman/listinfo/python-list
Re: Flag control variable
Op woensdag 12 februari 2014 17:10:36 UTC+1 schreef Alain Ketterlin: luke.gee...@gmail.com writes: Can I make it that if C = int(sys.argv[3]) But when I only enter 2 argumentvariable it sets c automaticly to 0 or 1 C = int(sys.argv[3]) if len(sys.argv) 3 else 0 is one possibility. -- Alain. thanks a lot -- https://mail.python.org/mailman/listinfo/python-list
Flag control variable
hello, i'd like to know how to set up a flag to change a variable, for example, i want a simple script to combine 2 numbers, sum = num + another_num print Now the sum of the numbers equals : , sum how could i make it so that if i type python ./script.py 21 41 that i get the sum of 21 and 41 ? luke -- https://mail.python.org/mailman/listinfo/python-list
Re: Flag control variable
Thanks a lot -- https://mail.python.org/mailman/listinfo/python-list
Re: Flag control variable
when expandig the script to multiple calcs i got a problem a = 32 c = 51 sign = * File stdin, line 1 sign = * ^ SyntaxError: invalid syntax is there a way of adding * without quoting marks, because if you do it just soms the arguments -- https://mail.python.org/mailman/listinfo/python-list
Re: Flag control variable
well i'm trying something else but no luck : #!bin/bash/python import sys import os a = int(sys.argv[1]) sign = (sys.argv[2]) b = int(sys.argv[3]) if sign == '+': sum = a + b print a, sign, b, =, a + b command1 = sudo mpg321 'http://translate.google.com/translate_tts?tl=enq=%s_plus%s_equals%s' % (a, b, sum) os.system (command1) elif sign == *: sum = a * b print a, sign, b, =, a * b command1 = sudo mpg321 'http://translate.google.com/translate_tts?tl=enq=%s_times%s_equals%s' % (a, b, sum) when using * i get Traceback (most recent call last): File ./math+.py, line 6, in module b = int(sys.argv[3]) ValueError: invalid literal for int() with base 10: 'Adafruit-Raspberry-Pi-Python-Code' i don't understand why b is a problem, it works fine with + -- https://mail.python.org/mailman/listinfo/python-list
Re: Flag control variable
Op dinsdag 11 februari 2014 19:55:59 UTC+1 schreef Gary Herron: On 02/11/2014 10:37 AM, luke.gee...@gmail.com wrote: well i'm trying something else but no luck : #!bin/bash/python import sys import os a = int(sys.argv[1]) sign = (sys.argv[2]) b = int(sys.argv[3]) if sign == '+': sum = a + b print a, sign, b, =, a + b command1 = sudo mpg321 'http://translate.google.com/translate_tts?tl=enq=%s_plus%s_equals%s' % (a, b, sum) os.system (command1) elif sign == *: sum = a * b print a, sign, b, =, a * b command1 = sudo mpg321 'http://translate.google.com/translate_tts?tl=enq=%s_times%s_equals%s' % (a, b, sum) when using * i get Traceback (most recent call last): File ./math+.py, line 6, in module b = int(sys.argv[3]) ValueError: invalid literal for int() with base 10: 'Adafruit-Raspberry-Pi-Python-Code' i don't understand why b is a problem, it works fine with + Look at the error message. Carefully! It says, quite clearly, the call to int is being passed a string Adafruit-Raspberry-Pi-Python-Code, which of course can't be converted to an integer. Now the question is how you ran the program in such a manner that sys.argv[3] has such an odd value. What does your command line look like? You didn't tell us, but that's where the trouble is. Gary Herron how do you meen what does your command line look like? -- https://mail.python.org/mailman/listinfo/python-list
Re: Flag control variable
Op dinsdag 11 februari 2014 19:51:40 UTC+1 schreef Peter Otten: luke.gee...@gmail.com wrote: well i'm trying something else but no luck : #!bin/bash/python Hm. import sys import os For debugging purposes put the line print sys.argv here to see what arguments are passed to the script. When you type $ python script.py 2 * 2 in the shell the * sign is replaced with all items in the current directory. To avoid that you have to escape, i. e. prepend a backslash: $ python script.py 2 \* 2 To illustrate: $ touch one two three $ ls one three two $ python -c 'import sys; print sys.argv' 2 + 2 ['-c', '2', '+', '2'] $ python -c 'import sys; print sys.argv' 2 * 2 ['-c', '2', 'one', 'three', 'two', '2'] $ python -c 'import sys; print sys.argv' 2 \* 2 ['-c', '2', '*', '2'] a = int(sys.argv[1]) sign = (sys.argv[2]) b = int(sys.argv[3]) if sign == '+': sum = a + b print a, sign, b, =, a + b command1 = sudo mpg321 'http://translate.google.com/translate_tts?tl=enq=%s_plus%s_equals%s' % (a, b, sum) os.system (command1) elif sign == *: sum = a * b print a, sign, b, =, a * b command1 = sudo mpg321 'http://translate.google.com/translate_tts?tl=enq=%s_times%s_equals%s' % (a, b, sum) when using * i get Traceback (most recent call last): File ./math+.py, line 6, in module b = int(sys.argv[3]) ValueError: invalid literal for int() with base 10: 'Adafruit-Raspberry-Pi-Python-Code' i don't understand why b is a problem, it works fine with + when using python script.py 2 \* 2 i get Traceback (most recent call last): File math2.py, line 5, in module sign = int(sys.argv[2]) ValueError: invalid literal for int() with base 10: '*' -- https://mail.python.org/mailman/listinfo/python-list
Re: Flag control variable
Op dinsdag 11 februari 2014 20:01:05 UTC+1 schreef luke@gmail.com: Op dinsdag 11 februari 2014 19:51:40 UTC+1 schreef Peter Otten: luke.gee...@gmail.com wrote: well i'm trying something else but no luck : #!bin/bash/python Hm. import sys import os For debugging purposes put the line print sys.argv here to see what arguments are passed to the script. When you type $ python script.py 2 * 2 in the shell the * sign is replaced with all items in the current directory. To avoid that you have to escape, i. e. prepend a backslash: $ python script.py 2 \* 2 To illustrate: $ touch one two three $ ls one three two $ python -c 'import sys; print sys.argv' 2 + 2 ['-c', '2', '+', '2'] $ python -c 'import sys; print sys.argv' 2 * 2 ['-c', '2', 'one', 'three', 'two', '2'] $ python -c 'import sys; print sys.argv' 2 \* 2 ['-c', '2', '*', '2'] a = int(sys.argv[1]) sign = (sys.argv[2]) b = int(sys.argv[3]) if sign == '+': sum = a + b print a, sign, b, =, a + b command1 = sudo mpg321 'http://translate.google.com/translate_tts?tl=enq=%s_plus%s_equals%s' % (a, b, sum) os.system (command1) elif sign == *: sum = a * b print a, sign, b, =, a * b command1 = sudo mpg321 'http://translate.google.com/translate_tts?tl=enq=%s_times%s_equals%s' % (a, b, sum) when using * i get Traceback (most recent call last): File ./math+.py, line 6, in module b = int(sys.argv[3]) ValueError: invalid literal for int() with base 10: 'Adafruit-Raspberry-Pi-Python-Code' i don't understand why b is a problem, it works fine with + when using python script.py 2 \* 2 i get Traceback (most recent call last): File math2.py, line 5, in module sign = int(sys.argv[2]) ValueError: invalid literal for int() with base 10: '*' i found it int(sys.argv[2]) should be sys.argv[2] is there a way i can do python ./script.py 3 * 3 instead of python ./script 3 \* 3 ? -- https://mail.python.org/mailman/listinfo/python-list
Re: Flag control variable
Op dinsdag 11 februari 2014 20:28:44 UTC+1 schreef Tim Chase: On 2014-02-11 11:06, luke.gee...@gmail.com wrote: command1 = sudo mpg321 'http://translate.google.com/translate_tts?tl=enq=%s_times%s_equals%s' 1) PLEASE either stop using Google Groups or take the time to remove the superfluous white-space you keep adding to your posts/replies 2) you shouldn't need to use sudo to play sounds. That's just a bad practice waiting for trouble. -tkc its one rule in the original (at least on my computer) -- https://mail.python.org/mailman/listinfo/python-list
Re: Flag control variable
hey, i got another problem now, if i use the imterpreter to do 3 * 4 it gives twelve the script gives ? any tips -- https://mail.python.org/mailman/listinfo/python-list
Re: Flag control variable
Would it be possible to make an int(sys.argv[1]) Not needed and set value 0 ( or in another script 1) For example a = int(sys.argv[1]) b = int(sys.argv[2]) c = int(sys.argv[3]) And I run Python ./script.py 2 3 It just set c automaticly to 0 or 1 Luke (PS thanks for the quick help) -- https://mail.python.org/mailman/listinfo/python-list
Re: Flag control variable
Can I make it that if C = int(sys.argv[3]) But when I only enter 2 argumentvariable it sets c automaticly to 0 or 1 -- https://mail.python.org/mailman/listinfo/python-list
[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
pyjamas 0.8.1 - help requested for testing to reach stable release
hi folks, got a small favour to ask of the python community - or, more specifically, i feel compelled to alert the python community to a need with which you may be able to help: we're due for another release, and it's becoming an increasingly-large task. given the number of examples requiring testing (75+) the number of browsers (15+) and desktop engines (3 so far, on 3 different OSes) that pyjamas supports is just... overwhelming for any one individual to even contemplate tackling. for the pyjamas 0.6 release, for example, i spent three weeks straight, just doing testing. from that experience i decided to set a rule, which is very straightforward: ask for help in testing, set a (reasonably firm) deadline for a release date, and then whatever has been tested by contributors by that time, that becomes the stable release. thus, in this way, the community receives a stable release that is of the quality that the *community* requires. the list of platforms tested already is quite long: however it's not long _enough_! and, also, on each task, there needs to be many more examples actually tested. here's what's been done so far: http://code.google.com/p/pyjamas/issues/list?can=2q=milestone=Release0.8.1 we need more testing on opera, more testing on safari, more versions of firefox - more of everything basically! so, this is basically more of a notification than it is anything else, that if you'd like to help with the responsible task of ensuring that a python compiler and GUI toolkit has a release that the python community can be proud of, that i'm placing that responsibility directly into your hands: i'm just the gatekeeper, here. lastly, i'd like to leave you with this thought. i am doing a web site for a client (a general-purpose content management system which will be released as free software at some stage). the user management roles are stored as a comma-separated list in the database (kirbybase). i needed to split the string back into a list, and before i knew it i had typed this: import string roles = map(string.strip, user['roles'].split(,)) what struck me was that, although i've been working with pyjamas for over three years, it _still_ had me doing a double-take that this is *python*, yet this will end up running in *javascript* in the actual web site. the level of pain and awkwardness that would need to be gone through in order to do the same operation in javascript, and being completely unable to actually test and develop with confidence under pyjd directly at the python interpreter, i just... i can't imagine ever going back to that. and that's just... fricking awesome, but it highlights and underscores that there's a real reason why pyjamas is worthwhile helping out with (and using). you *do not* have to learn javascript, yet can still create comprehensive web sites that will work across all modern web browsers... *if* they're tested properly :) ok enough. thanks folks. l. -- http://mail.python.org/mailman/listinfo/python-list
pyjamas pyjs.org domain has been hijacked
i have an apology to make to the python community. about 3 or 4 months ago a number of the pyjamas users became unhappy that i was sticking to software (libre) principles on the pyjamas project. they saw the long-term policy that i had set, of developing python-based pyjamas-based infrastructure (such as pygit) for pyjamas to become a demonstration of its own technology, as being unnecessarily restrictive, and for their convenience, they requested the use of non-free hosting services such as github, google groups and so on. i patiently explained why this was not acceptable as i am software (libre) developer, and advised them that if they wanted such services, perhaps they could help themselves to learn pyjamas and python by helping to improve the existing infrastructure, and that i would be happy to help them do so. many of them did not understand or accept. what i did not realise was happening, until it was announced a few hours ago, was that in the intervening time a number of the pyjamas users had got together to develop alternative infrastructure which makes use of non-free hosting facilities such as github, and that they also planned to hijack the pyjs.org domain... *without* consulting the 650 or so members on the pyjamasdev mailing list, or the python community at large. so this is rather embarrassing because i had just put out a request for help to the wider python community, with the pyjamas 0.8.1 release, when it turns out that 12 hours later the domain has been hijacked. my first apology therefore is this: i apologise to the python community for being a cause of disruption. the second apology is - if priority can ever be applied to apologies at all - is i feel somewhat more important. i am a free (libre) software developer, and i am a teacher, as many of you will know from the talks that i have given on pyjamas at various conferences. i lead by example, and it is not just free software development itself that i teach, but also free software principles. this was why i set the long-term policy that pyjamas should migrate to running on python-based server infrastructure and pyjamas-based web front-end applications, *even* for its own development, because the most fundamental way to teach is to lead by example. my apology is therefore for the disruption caused to the pyjamas project - and to the python community - as a direct consequence of me wishing to uphold software (libre) principles, and for using the pyjamas project as a way to do that. that may sound incredibly strange, especially to those people for whom software (libre) principles are something that they just accept, but it is a genuine apology, recognising that there are people for whom free software principles are not of sufficient importance to have their day-to-day development made inconvenient. i don't know what else to say, so i'll leave it at that. sorry folks. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: pyjamas pyjs.org domain has been hijacked
... i'm reeally really sorry about this, but it suddenly dawned on me that, under UK law, a breach of the UK's data protection act has occurred, and that the people responsible for setting up the hijacked services have committed a criminal offense under UK law. ordinarily, a free software mailing list would be transferred to alternative services through the process of soliciting the users to enter into an implicit contract over a legally-enforceable reasonable amount of time, as follows: in 30 days we will move the mailing list. anyone who doesn't want their personal data moved to the new server please say so. unfortunately, in this case, i have to advise that no such announcement had been made. although i gave permission to one of the people who has hijacked the domain my permission to aid and assist in the administration of the server, i did NOT give them permission to do anything else. unfortunately, they then abused the trust placed in them in order to gain unauthorised access to the machine. in this way, the data (ssh keys and user's email addresses) was copied WITHOUT my express permission (constituting unauthorised computer access and misuse of a computer), but worse than that WITHOUT the permission of the users who own their data (ssh keys and email addresses). as it's 2am here in the UK and also i will be travelling for the next couple of days, and also to preserve the state of the machine as evidence, i have had to shut down the XEN instance and will not be in a convenient position to access the email addresses in order to directly notify the users of the UK Data Protection Act breach. so for now, this announcement (to the python list, of all places) will have to do. for which i apologise, again, for having to inconvenience others who may not be interested in what has transpired. but to all concerned i apologise again, deeply, for putting everyone to trouble just because i decided to stick to free software principles. strange as that sounds. i honestly didn't see this coming. l. -- http://mail.python.org/mailman/listinfo/python-list
[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
Re: Framework for a beginner
On Thu, Apr 19, 2012 at 12:20 PM, Alek Storm alek.st...@gmail.com wrote: On Wed, Apr 18, 2012 at 11:21 PM, lkcl luke.leigh...@gmail.com wrote: On Apr 11, 9:11 pm, biofob...@gmail.com wrote: I am new to python and only have read the Byte of Python ebook, but want to move to the web. I am tired of being a CMS tweaker and after I tried python, ruby and php, the python language makes more sense (if that makes any sense for the real programmers). yeah, it does :) python is... the best word i can describe it is: it's beautiful. it has an elegance of expression that is only marred by the rather silly mistake of not taking map, filter and reduce into the list object itself: l.map(str) for example would be intuitive, compact and elegant. instead, i have to look up how to use map each and every damn time! the reason for the mistake is historical: map, filter and reduce were contributed by a lisp programmer. that lisp programmer, presumably, was used to everything being function(args...) and it simply didn't occur to anyone to properly integrate map, filter and reduce properly into the list objects that they work with. Why not use list comprehension syntax? because it's less characters to type, and thus less characters to read. i find that syntax incredibly klunky. left to right you're reading, you declare something to be the case... and then oh whoops actually it's not really the case because it's modified by a list thing - it breaks reading expectations. that's what i meant about beauty and elegance. the bang per buck ratio in python, results obtained for the number of characters used, is higher, and that's something that i personally find to be a priority over speed. you don't *have* to use lambdas with map and reduce, you just have to use a function, where a lambda happens to be a nameless function. another example of the compactness of python is kicking around somewhere, i wish i could remember where it is. it compares scheme with python and java. scheme does this amazing programming thing in a single operator, expressed in 3 characters. python manages the same thing in about 10, and java requires *six* lines! It gets you map and filter functionality for free, and is more readable than python's clunky version of lambdas. I believe they're faster than the for-loop equivalents, but I'm not sure about the actual map() and filter() functions (reduce() was removed from 3.0 for reasons I will never understand). likewise. /salutes -- http://mail.python.org/mailman/listinfo/python-list
Re: Framework for a beginner
On Thu, Apr 19, 2012 at 1:21 PM, Alek Storm alek.st...@gmail.com wrote: On Thu, Apr 19, 2012 at 7:12 AM, lkcl luke luke.leigh...@gmail.com wrote: On Thu, Apr 19, 2012 at 12:20 PM, Alek Storm alek.st...@gmail.com wrote: Why not use list comprehension syntax? because it's less characters to type, and thus less characters to read. i find that syntax incredibly klunky. left to right you're reading, you declare something to be the case... and then oh whoops actually it's not really the case because it's modified by a list thing - it breaks reading expectations. that's what i meant about beauty and elegance. the bang per buck ratio in python, results obtained for the number of characters used, is higher, and that's something that i personally find to be a priority over speed. Did I miss something? `[a+1 for a in some_list]` is shorter than both `map(lambda a: a+1, some_list)` and `some_list.map(lambda a: a+1)`. :) yes you missed something. :) a) if you use that lambda a:a+1 a lot, you make it an actual function, don't you? even for clarity you'd still probably use a function not a lambda. i use map quite a lot, filter and reduce not so much. a more real-world example was one that i actually gave initially: map(str, l). or, the syntax i really prefer which doesn't exist: l.map(str). or, one that i also use in web applications or their back-ends: map(int, l). if you have a comma-separated set of variables in a single string, like this: 5, 20, 3, i tend to use this: from string import strip l = map(int, map(strip, l.split(,))) ok to make it clearer i sometimes do that on 3 separate lines. i'd _love_ it to be this: l = l.split(,).map(strip).map(int) or even better would be this: l = l.split(,).map(strip, int) b) read the text from left to right, in plain english: * map(str, l): you're going to map i.e. apply a string function to a list's members. (now you see why i keep getting confused with map, because the natural language version of this is map a list's members to a string - the other way round) * a+1 for a in l: take an expression which is a mathematical operation and therefore has the expectation that its arguments are mathematical in nature. then oh damn it wait a minute, actually there's more going on here: for every variable in a list, use the variables in the expression to make a new list... i'm belabouring the point (not entirely intentionally) but you see how clumsy that is? it's probably just as complex in the actual lexer/grammar file in the http://python.org source code itself, as it is to think about in real life and to psychologically parse in english. you actually have to think *backwards*! is that clearer, or have i added mud? :) l. -- http://mail.python.org/mailman/listinfo/python-list
[ANN] Pyjamas-Gitweb 0.1 released
http://pypi.python.org/pypi/Pyjamas-GitWeb/0.1 Pyjamas-Gitweb is a pure python git repository browser, comprising an independent JSONRPC back-end service written in 130 lines that can be used by any JSONRPC client (a python command-line example is included), and a front-end python (pyjamas) written in 350 lines. In combination with the back-end service, the front-end may either be compiled to javascript and used on the web or it may be run directly in python for use as a desktop git repository browser. in other words, it's not much to look at, but it's kinda cool and it does the job. here's a working demo where you can browse the source code with itself: http://pyjs.org/pygit/pygit.html?repo=pyjamasgitweb.git l. -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
[ANN] Pyjamas-Gitweb 0.1 released
http://pypi.python.org/pypi/Pyjamas-GitWeb/0.1 Pyjamas-Gitweb is a pure python git repository browser, comprising an independent JSONRPC back-end service written in 130 lines that can be used by any JSONRPC client (a python command-line example is included), and a front-end python (pyjamas) written in 350 lines. In combination with the back-end service, the front-end may either be compiled to javascript and used on the web or it may be run directly in python for use as a desktop git repository browser. in other words, it's not much to look at, but it's kinda cool and it does the job. here's a working demo where you can browse the source code with itself: http://pyjs.org/pygit/pygit.html?repo=pyjamasgitweb.git l. -- http://mail.python.org/mailman/listinfo/python-list
Pyjamas 0.8.1~+alpha1 released
This is the 0.8.1~+alpha1 release of Pyjamas. Pyjamas comprises several projects, one of which is a stand-alone python-to-javascript compiler; other projects include a Graphical Widget Toolkit, such that pyjamas applications can run either in web browsers as pure javascript (with no plugins required) or stand-alone on the desktop (as a competitor to PyGTK2 and PyQT4). This announcement marks the beginning of the pyjamas 0.8.1 release candidates. Operating Systems, Browsers and Desktop Engines tested so far are listed here: http://code.google.com/p/pyjamas/issues/list Downloads are available from the usual places: http://pypi.python.org/pypi/Pyjamas https://sourceforge.net/projects/pyjamas/files/pyjamas/0.8.1/ Pyjamas is slowly converting to running its own infrastructure using pyjamas applications (which also operate as Desktop applications). This includes: * http://pyjs.org/pygit/ - a git repository viewer using python-git * http://lists.pyjs.org/mail/ - a list viewer using lamson's json archive * http://pyjs.org - a simple web engine using AJAX to get HTML pages * the wiki http://pyjs.org/wiki is next (using python-dulwich) The full source code of each of these applications is available and can be used for projects and purposes other than for pyjamas itself. The README is available here: http://pyjs.org/pygit/#file=READMEid=0d4b6787d01c3d90f2c8801c5c4c45e34145bbddmimetype=text/plain -- http://mail.python.org/mailman/listinfo/python-list
[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
Re: Question about pyjamas inner workings (pyjd's version of imputil.py)
[i'm bcc'ing this to python-list because it's something that is generic to python, not pyjamas] On Tue, Jun 7, 2011 at 4:38 PM, Alexander Tsepkov atsep...@gmail.com wrote: I'm working on a python-based side project where I want to be able to generate multiple variations of the program and I really like the way pyjamas handles this same problem with the browsers by pulling in variations from __safari__, __ie6__, etc. It seems very elegant to just define the actual functions that change rather than copy-pasting entire code and having to maintain the same class in multiple places. One way I was thinking of dealing with this is to use regular expressions to scan these functions and classes, but I feel like there would be too many special cases with indentations that I would need to address. I'm trying to understand the mechanism by which pyjamas does this so I can apply something similar to my python code. ok, then just use pyjd/imputil.py. it's a modified - bug-fixed - version of the standard version of the python imputil.py which has then been modified to include the platform overrides concept, as well. the problem(s) with the standard version of imputil.py include that it failed to perform the correct import operations as compared to standard built-in (c-code) python import behaviour. one of the very first things i had to do was to fix the bugs and broken behaviour in imputil.py the second important thing that i had to do was, to instead of looking up just the cached .pyc pre-compiled byte code file, but also look up the platform override pre-compiled byte code file... *and* also make sure that, if there existed a platform override .py file *and* the original / base .py file, the platform override bytecode was thrown away. i.e. it's a leetle more complex than just let's look at the timestamp on the .pyc file, compare it to the timestamp of the .py file. for those people on python-list who may not be familiar with the platform overrides system in pyjamas, it's a fantastic concept where, instead of doing ridiculous amounts of if platform == 'win32' do xyz elif platform == 'cygwin' do abc elif elif elif elif elif elif elif [i'm sure you get the idea] you just have one base file e.g. compiler.py and then you have overrides compiler.win32.py or compiler.cygwin.py etc. etc. in these overrides, you have classes with methods with the *exact* same name as in the base file, and the [heavily-modified] imputil.py performs an AST-level merge prior to byte-code compilation. the technique forces a clean and clear separation of an API from the functionality behind the API, with these overrides providing Object-Orientated design methodology at a base system level. l. -- http://mail.python.org/mailman/listinfo/python-list
pythonwebkit-gtk, pythonwebkit-dfb
in preparation for a 0.8 release of pyjamas, a bit of work has been done on pythonwebkit (http://www.gnu.org/software/pythonwebkit) that makes it easier to compile and install. pythonwebkit provides full and complete (see caveats below!) bindings to web browser functionality... in python. what you would normally expect to be able to do in javascript in-browser, you can do EXACTLY the same thing, in a declarative programming style, in python: import gtk import pywebkitgtk url = http://www.gnu.org/software/pythonwebkit; wv = pywebkitgtk.WebView(1024,768, url=url) def _doc_loaded(*args): doc = wv.GetDomDocument() txt = doc.createTextNode(hello) doc.body.appendChild(txt) wv.SetDocumentLoadedCallback(_doc_loaded) gtk.main() yes, that's really python, doing a createTextNode and an appendChild, *not* javascript. not interpreted javascript, not interpreted python, *real* python, byte-coded and everything. throw in some AJAX, some browser event callbacks (onclick etc.) and some web browser timer callbacks and it all starts to get a bit weird, as two or maybe three disparate programming worlds that should never really have been brought together suddenly.. um... well, are brought together. the bit that's easier about installing pythonwebkit is that it is no longer necessary to download and patch up the http://code.google.com/p/pywebkitgtk project in order to use pythonwebkit. you can simply do ./autogen.sh followed by the usual make and make install. a new and absolute minimalist python module is created and installed which will get you a blank window - just like if you were firing up a python-GTK application or a python-QT4 application. anyway - just a bit of an informal not-really-announcement because, well, it's a side-dependency to the pyjamas project, even if it is a whopping 20mb one. those caveats btw are that a) you can't set CSS properties as if they were python object properties: you have to use the method setProperty, duh, and b) there are *no* 2D or 3D SVG Canvas objects or functions available, yet, because it would take a good full-time 7 to 10 days to smack the codegenerator into shape and i'm waiting for someone to step forward and fund that work. am still servicing £20,000 in debt and still have to find a way to pay back a complete stranger who incredibly kindly paid £4,000 in owed rent so that we did not end up with a County Court Judgement against us. myself, my partner and our 25 month old daughter still got evicted, but that's another story. against this kind of background, perhaps i might be forgiven for not doing freebie free software development, i trust. l. -- http://mail.python.org/mailman/listinfo/python-list
[ann] pyjamas 0.8alpha1 release
after a long delay the pyjamas project - http://pyjs.org - has begun the 0.8 series of releases, beginning with alpha1: https://sourceforge.net/projects/pyjamas/files/pyjamas/0.8/ pyjamas is a suite of projects, including a python-to-javascript compiler with two modes of operation (roughly classified as python strict and Optimised); a GUI Framework almost identical to that of the GWT Project (1.5 to 1.7); and a Desktop version which is similar in concept to Adobe Air, allowing python applications to be run - unmodified - as stand-alone Desktop Applications. pyjamas can therefore be considered to be a Desktop GUI framework - a peer of GTK2 and QT4 - with the startling capability that applications can also be compiled to javascript and run in any modern web browser with absolutely no special plugins required, or it can be considered to be an AJAX Web Framework with the massive advantage that applications are written in python (not javascript) with a Desktop mode as well. both descriptions are accurate, making pyjamas the world's only free software python-based platform-independent, browser-independent, GUI-toolkit-independent and OS-independent Holy Grail GUI development environment [so there. nyer, nyer to the corporate big boys with access to $m who *still* haven't managed that one] also included are ports of GChart and GWTCanvas, each of which run under all web browsers and all desktop engines (with the exception at present of the python-webkit desktop engines, which presently do not support SVG Canvas). all pyjamas UI libraries are designed to be browser-independent as well as platform independent. the usual browser foibles, tricks and gotchas are catered for with a transparent Platform Override mechanism which ensures that the published API of each UI Library is identical across all platforms (including the Desktop Engines). [no more If Platform == IE or Platform == Opera] due to the sheer number of modern browsers as well as the number of pyjamas-desktop engines required to be supported, the 0.8 series will be ready declared stable when sufficient community-led testing has been done. bugreports are in for Opera 11, IE8 and Google Chrome: http://code.google.com/p/pyjamas/issues/detail?id=600 http://code.google.com/p/pyjamas/issues/detail?id=601 http://code.google.com/p/pyjamas/issues/detail?id=597 still requiring testing and confirmation is Opera 9 and 10; Firefox 2, 3, 3.1, 3.5, 3.6 and 4.0; IE6, 7 and 9; Safari 3 and 4, as well as mobile phone browsers Android, Symbian Series 60, iphone, ipad and blackberry OS 4. also requiring testing and confirmation is the Desktop Engines, of which there are now four variants: XulRunner (Firefox Engine), pywebkitgtk, MSHTML and the new addition pywebkitdfb (DirectFB). each browser and each engine requires each of the 70 examples to be run, and in the case of the pyjamas compiler (pyjs), compilation is required with both -O and --strict (with the exception of the LibTest example). the pywebkitdfb engine is a new addition, and merits a particular mention. some time last year, both GTK2 and QT4 independently announced that they were dropping support for DirectFB from future versions, and Enlightenment had not tested the DirectFB port for some considerable time. Webkit-GTK with the older GTK-DirectFB libraries simply would not compile. in the embedded space, where it can take 30 seconds to fire up Webkit-GTK on a 400mhz ARM9 and even longer to start up WebkitQT4, this was something of a disaster. To fix this, a new port of Webkit was created which uses DirectFB directly, using a tiny 50k Widget Toolkit called Lite. This development coincided with the re-engineering of pywebkitgtk and the creation of the pythonwebkit project, http://www.gnu.org/software/pythonwebkit: pywebkitdfb was therefore also created at the same time. Cutting a long story short, pywebkitdfb now exists and has a startup time on 400mhz ARM9 processors of under 1.5 seconds. The startup time of both WebkitDFB and pywebkitdfb on Dual-Core 2ghz Intel systems is so quick that it's difficult to determine: an estimate is under 0.1 seconds (100ms). WebkitGTK. WebkitEFL and WebkitQT4 have approximately 20 times or longer startup times. So although WebkitDFB is still significantly experimental, it is definitely worthwhile considering, especially for Embedded Systems, but even for use on X-Windows, and even just as a plain (but modern) web browser for those people sick to the back teeth of long startup times on their web browser [and it has python bindings, too. yaay!] summary: developing applications in pyjamas means the application can be made to run just about anywhere, and it's an entirely python-based and a free software framework. it's a community-driven project, so requires *your* input to get it to a proven stable state. http://pyjs.org -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation:
[ann] pyjamas 0.8alpha1 release
after a long delay the pyjamas project - http://pyjs.org - has begun the 0.8 series of releases, beginning with alpha1: https://sourceforge.net/projects/pyjamas/files/pyjamas/0.8/ pyjamas is a suite of projects, including a python-to-javascript compiler with two modes of operation (roughly classified as python strict and Optimised); a GUI Framework almost identical to that of the GWT Project (1.5 to 1.7); and a Desktop version which is similar in concept to Adobe Air, allowing python applications to be run - unmodified - as stand-alone Desktop Applications. pyjamas can therefore be considered to be a Desktop GUI framework - a peer of GTK2 and QT4 - with the startling capability that applications can also be compiled to javascript and run in any modern web browser with absolutely no special plugins required, or it can be considered to be an AJAX Web Framework with the massive advantage that applications are written in python (not javascript) with a Desktop mode as well. both descriptions are accurate, making pyjamas the world's only free software python-based platform-independent, browser-independent, GUI-toolkit-independent and OS-independent Holy Grail GUI development environment [so there. nyer, nyer to the corporate big boys with access to $m who *still* haven't managed that one] also included are ports of GChart and GWTCanvas, each of which run under all web browsers and all desktop engines (with the exception at present of the python-webkit desktop engines, which presently do not support SVG Canvas). all pyjamas UI libraries are designed to be browser-independent as well as platform independent. the usual browser foibles, tricks and gotchas are catered for with a transparent Platform Override mechanism which ensures that the published API of each UI Library is identical across all platforms (including the Desktop Engines). [no more If Platform == IE or Platform == Opera] due to the sheer number of modern browsers as well as the number of pyjamas-desktop engines required to be supported, the 0.8 series will be ready declared stable when sufficient community-led testing has been done. bugreports are in for Opera 11, IE8 and Google Chrome: http://code.google.com/p/pyjamas/issues/detail?id=600 http://code.google.com/p/pyjamas/issues/detail?id=601 http://code.google.com/p/pyjamas/issues/detail?id=597 still requiring testing and confirmation is Opera 9 and 10; Firefox 2, 3, 3.1, 3.5, 3.6 and 4.0; IE6, 7 and 9; Safari 3 and 4, as well as mobile phone browsers Android, Symbian Series 60, iphone, ipad and blackberry OS 4. also requiring testing and confirmation is the Desktop Engines, of which there are now four variants: XulRunner (Firefox Engine), pywebkitgtk, MSHTML and the new addition pywebkitdfb (DirectFB). each browser and each engine requires each of the 70 examples to be run, and in the case of the pyjamas compiler (pyjs), compilation is required with both -O and --strict (with the exception of the LibTest example). the pywebkitdfb engine is a new addition, and merits a particular mention. some time last year, both GTK2 and QT4 independently announced that they were dropping support for DirectFB from future versions, and Enlightenment had not tested the DirectFB port for some considerable time. Webkit-GTK with the older GTK-DirectFB libraries simply would not compile. in the embedded space, where it can take 30 seconds to fire up Webkit-GTK on a 400mhz ARM9 and even longer to start up WebkitQT4, this was something of a disaster. To fix this, a new port of Webkit was created which uses DirectFB directly, using a tiny 50k Widget Toolkit called Lite. This development coincided with the re-engineering of pywebkitgtk and the creation of the pythonwebkit project, http://www.gnu.org/software/pythonwebkit: pywebkitdfb was therefore also created at the same time. Cutting a long story short, pywebkitdfb now exists and has a startup time on 400mhz ARM9 processors of under 1.5 seconds. The startup time of both WebkitDFB and pywebkitdfb on Dual-Core 2ghz Intel systems is so quick that it's difficult to determine: an estimate is under 0.1 seconds (100ms). WebkitGTK. WebkitEFL and WebkitQT4 have approximately 20 times or longer startup times. So although WebkitDFB is still significantly experimental, it is definitely worthwhile considering, especially for Embedded Systems, but even for use on X-Windows, and even just as a plain (but modern) web browser for those people sick to the back teeth of long startup times on their web browser [and it has python bindings, too. yaay!] summary: developing applications in pyjamas means the application can be made to run just about anywhere, and it's an entirely python-based and a free software framework. it's a community-driven project, so requires *your* input to get it to a proven stable state. http://pyjs.org -- http://mail.python.org/mailman/listinfo/python-list
