I have a question about Python programming language can help you glad you
do. User as a decimal point "." Instead of character "," we can use that
character? For example, 10.7 instead of 10,7
Thanks in advance ...
I'm still no-mail on python-dev, forwarding as FYI
----- Forwarded message from Eric Albrecht <eric.albrecht(a)Nichecubed.com> -----
From: Eric Albrecht <eric.albrecht(a)Nichecubed.com>
To: "webmaster(a)python.org" <webmaster(a)python.org>
Date: Thu, 10 Sep 2009 10:48:11 -0400
Subject: Front Runner Program
Regarding: Windows 7 Compatibility for Python Application.
I am trying to contact your company regarding the Microsoft Windows 7 Compatibility Program for the application above. I have not been able to get in touch with the person responsible for this application in your company and this is why I am reaching out to you through the Support Team. This application has been identified as one of the applications Microsoft would like to see supported on Windows 7 and I have been tasked by Microsoft to help answer your questions about Windows 7 application compatibility and help you get your application through the Windows 7 "Green Light" compatibility process.
If your application already supports Windows Vista, chances are it will already be compatible with Windows 7 without the need for any code changes. By pledging support for Windows 7 you're application will automatically be listed in the Windows Application Compatibility seen currently by more than 1 million users per month. The registration is extremely simple and just asks a few key questions.
Here is the link to Microsoft's ISV Application Compatibility page: www.isvappcompat.com<http://www.isvappcompat.com/> . When you have a moment, I would encourage you to visit the site and complete the process to pledge support for your application on Windows 7 by October 22nd 2009 when Windows 7 is officially released.
In addition if you are able to pledge compatibility you'll receive access to a special Windows 7 Partner Marketing Kit that includes a press release with a Microsoft quote, plus customizable marketing templates including; email templates, postcards, web banners, business letter, and copy blocks, all to identify to your customers, or potential customers that your solutions are compatible with Windows 7.
If you provide me with a phone number where to get in touch with you, I will call you to answer any questions you may have.
Once you register on the ISV Application Compatibility site, I would appreciate it if email me to let me know that you have completed so that I can make a note of it for Microsoft. If you register the application under a different partner or application name please let me know in order to track changes. If there is a new version of the application and there are no plans to support Windows 7 on the older version please register the older version as "No planned Support" on the site as well as the new version with desired Win7 compatibility date.
Should you have any questions about this email feel free to call me or send an email to my supervisor at v-mafl(a)microsoft.com<mailto:firstname.lastname@example.org>.
800-508-4291 EXT: 309
----- End forwarded message -----
Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/
"To me vi is Zen. To use vi is to practice zen. Every command is a
koan. Profound to the user, unintelligible to the uninitiated. You
discover truth everytime you use it." --reddy(a)lion.austin.ibm.com
I have been working on adding asynchronous I/O to the Python
subprocess module as part of my Google Summer of Code project. Now
that I have finished documenting and pruning the code, I present PEP
3145 for its inclusion into the Python core code. Any and all feedback
on the PEP (http://www.python.org/dev/peps/pep-3145/) is appreciated.
David Lyon wrote:
> On Tue, 08 Sep 2009 09:18:50 +0100, Chris Withers <chris(a)simplistix.co.uk>
>> <mini rant>
>> If Python had a packaging system *and* used it for the standard library,
>> then things like this wouldn't be a problem...
>> The setup.cfg could just say "requires sqlite greater than version
>> x.y.z", and if it was in the standard library, it would be used unless a
>> newer version was needed.
> Actually, this was already discussed on this mailing list.
Yeah, I know, but I had memories of it be poo-poo'ed on Python-Dev...
(CC'ing so they can tell me I'm wrong ;-) )
> I suggested that a "requires" section could easily do this, something
> along the lines of:
Tarek, How are requirements spelled for packages in your current setup.cfg?
I really don't see why anything should be different for standard library
packages (ie: the stdlib= prefix in David's example). Python
distributions should just declare all the versions they come with in the
same way that whatever-is-being-built by Tarek can introspect in the
same way as any other package...
> So the concept of having an if/else test for this is superfluous.
>> It would also mean it would be possible to
>> release bug fix versions of the standard library packages without having
>> to roll a whole python release.
...which in turn would mean that the standard library is no longer a
place where packages go to die...
>> Better yet, since "python" should be a package as far as the packaging
>> system is concerned, library versions can just say what versions of
>> python they work with.
> +1 - good idea
...and for me, the "python" package should be just another package in
the distributions dance, called "python" ;-)
Simplistix - Content Management, Batch Processing & Python Consulting
hey, has anyone investigated compiling python2.5 using winegcc, under wine?
i'm presently working my way through it, just for kicks, and was
wondering if anyone would like to pitch in or stare at the mess under
it's not as crazed as it sounds. cross-compiling python2.5 for win32
with mingw32 is an absolute miserable bitch of a job that goes
horribly wrong when you actually try to use the minimalist compiler to
do any real work.
so i figured that it would be easier to get python compiled using
wine. i _have_ got some success - a python script and a python.exe.so
(which is winegcc's friendly way of telling you you have something
that stands a chance of working) as well as a libpython25.dll.so.
what i _don't_ yet have is an _md5.dll (or should it be _md5.lib?)
i.e. the standard modules are a bit... iffy. the _winreg.o is
compiled; the _md5.o is compiled; the winreg.lib is not. whoops.
plus, it's necessary to enable nt_dl.c which is in PC/ _not_ in
one of the key issues that's a bit of a bitch is that python is
compiled up for win32 with a hard-coded pyconfig.h which someone went
to a _lot_ of trouble to create by hand instead of using autoconf. oh
- and it uses visualstudio so there's not even a Makefile. ignoring
that for the time-being was what allowed me to get as far as actually
having a python interpreter (with no c-based modules).
so there's a whole _stack_ of stuff that needs dragging kicking and
screaming into the 21st century.
there _is_ a reason why i want to do this. actually, there's two.
firstly, i sure as shit do _not_ want to buy, download, install _or_
run visual studio. i flat-out refuse to run an MS os and visual
studio runs like a dog under wine.
secondly, i want a python25.lib which i can use to cross-compile
modules for poor windows users _despite_ sticking to my principles and
keeping my integrity as a free software developer.
thirdly i'd like to cross-compile pywebkitgtk for win32
fourthly i'd like to compile and link applications to the extremely
successful and well wicked MSHTML.DLL... in the _wine_ project :) not
the one in windows (!) i want to experiment with DOM model
manipulation - from python - similar to the OLPC HulaHop project -
_but_ i want to compile or cross-compile everything from linux, not
windows (see 1 above)
fifthly i'd like to see COM (DCOM) working and pywin32 compiled and
useable under wine, even if it means having to get a license to use
dcom98 and oleauth.lib and oleauth.h etc. and all the developer files
needed to link DCOM applications under windows. actually what i'd
_really_ like to see is FreeDCE's DCOM work actually damn well
finished, it's only been eight years since wez committed the first
versions of the IDL and header files, and it's only been over fifteen
years since microsoft began its world domination using COM and DCOM.
... but that's another story :)
so that's ... five reasons not two. if anyone would like to
collaborate on a crazed project with someone who can't count, i'm
happy to make available what i've got up to so far, on github.org.
This is a repost from two weeks ago. It didn't get much feedback last
time. I still keep trying, reposting to python-list also this time.
In this thread, I'd like to collect things that ought to be done
but where Dirkjan has indicated that he would prefer if somebody else
The first item is build identification. If you want to work
on this, please either provide a patch (for trunk and/or py3k), or
(if you are a committer) create a subversion branch.
It seems that Barry and I agree that for the maintenance branches,
sys.subversion should be frozen, so we need actually two sets of
patches: one that removes sys.subversion entirely, and the other that
freezes the branch to the respective one, and freezes the subversion
revision to None.
The patch should consider what Dirkjan proposes as the branching
strategy: clones to separate 2.x and 3.x, as well as for features,
and branches with the clones for releases and maintenance (see the
PEP for details).
Anybody working on this should have good knowledge of the Python source
code, Mercurial, and either autoconf or Visual Studio (preferably both).
The second item is line conversion hooks. Dj Gilcrease has posted a
solution which he considers a hack himself. Mark Hammond has also
volunteered, but it seems some volunteer needs to be "in charge",
keeping track of a proposed solution until everybody agrees that it
is a good solution. It may be that two solutions are necessary: a
short-term one, that operates as a hook and has limitations, and
a long-term one, that improves the hook system of Mercurial to
implement the proper functionality (which then might get shipped
with Mercurial in a cross-platform manner).
Anyone know what's causing this failure?
test test___all__ failed -- Traceback (most recent call last):
File "Lib/test/test___all__.py", line 106, in test_all
File "Lib/test/test___all__.py", line 23, in check_all
exec("from %s import *" % modname, names)
File "<string>", line 1, in <module>
AttributeError: 'module' object has no attribute 'help'
Simplistix - Content Management, Batch Processing & Python Consulting
I noticed something (in 2.5) yesterday, which may be a feature, but is more likely a bug.
In tokenizer.c, tok->encoding is allocated using PyMem_MALLOC().
However, this then gets handed to a node->r_str in parsetok.c, and then released in node.c using PyObject_Free().
Now, by coincidence, PyObject_Free() will default to free() for objects that it doesn't recognize, so this works. But is this documented behavior? The reason I ran into this was that I had redirect the PyMem_* API to a different allocator, but left the PyObject_* one alone.
My feeling Is that these two APIs shouldn't be interchangeable. Especially since you can't hand a PyObject_Malloc'd object to PyMem_Free() so the inverse shouldn't be expected to work.