* Martin v. Loewis, on 08.07.2010 07:23:
And since things work for a single method when I declare 'def' as
'static', I suspect that means that the function object created by
PyCFunction_NewEx holds on to a pointer to the PyMethodDef structure?
Correct; it doesn't make a copy of the struct. So w
> I just
> couldn't get through on the python-dev list that I couldn't just
> upgrade my code to 2.6 and then use 2to3 to keep in step across the
> 2-3 chasm, as this would leave behind my faithful pre-2.6 users.
Not sure whom you had been talking to. But I would have tried to explain
that you don
Stephen Hansen wrote:
> You're doing string formatting
> to construct your SQL, which is where the trouble comes from.
You're wasting your breath, this topic has been discussed ad nauseum
with Victor for well over a year now. He appears to be teaching
himself relational db based web-development w
On 7/7/10 9:46 PM, "Martin v. Löwis" wrote:
>> I saw you already mentioned work toward this a few months (years ?)
>> ago. Is there some kind of roadmap, or could you use some help ? I
>> would really like to solve this issue as much as we possibly can,
>
> Well, Python 3 has already dropped stdio
> And since things work for a single method when I declare 'def' as
> 'static', I suspect that means that the function object created by
> PyCFunction_NewEx holds on to a pointer to the PyMethodDef structure?
Correct; it doesn't make a copy of the struct. So when you want the
function object to ou
Am 08.07.2010 04:17, schrieb imageguy:
>
>> I, too, have multiple versions installed -- newer ones for running code
>> I haven't upgraded; older ones for compatibility testing where needed.
>> I just install to the default c:\pythonxy directories (although I like
>> the idea of a common root) and
> The point, one more time with feeling, is that the incompatibilities
> between 2.x and 3.x will *increase* over time.
I think this is unfounded, and actually false.
Instead, the incompatibilities will *decrease* over the next few years.
Suppose you support 2.x and 3.x from a single code base. T
> Python 3.x will continue to change. The incompatibilities between 3.x
> and 2.x will only become more numerous. If your goal is to support
> 2.x, and 3.x, you'd be best supporting them separately.
I don't think that's a particularly good approach. Having a single code
base for both likely redu
On Jul 7, 10:55 pm, Carl Banks wrote:
> On Jul 7, 1:31 am, Paul McGuire wrote:
> > I just
> > couldn't get through on the python-dev list that I couldn't just
> > upgrade my code to 2.6 and then use 2to3 to keep in step across the
> > 2-3 chasm, as this would leave behind my faithful pre-2.6 user
Am 07.07.2010 23:10, schrieb Brendan Abel:
One thing that would be very useful is how to maintain something that
works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
versions below 2.6 is out of the question for most projects with a
significant userbase IMHO. As suc
On Wed, Jul 7, 2010 at 10:04 PM, David Cournapeau wrote:
>
> Decimal vs float is a different matter altogether: decimal has
> downsides compared to float. First, there is this irreconcilable fact
> that no matter how small your range is, it is impossible to represent
> exactly all (even most) numb
> I saw you already mentioned work toward this a few months (years ?)
> ago. Is there some kind of roadmap, or could you use some help ? I
> would really like to solve this issue as much as we possibly can,
Well, Python 3 has already dropped stdio for its own io library, and
I do want to get rid o
On 7/7/2010 10:49 PM, Ben Finney wrote:
Yes, that's what I meant. Python 3 is deliberately under no obligation
to support code that works in Python 2. If something needs fixing, and
that fix would involve breaking Python 2 code, then that's not a
consideration any more.
Code that works in 3.1
Dear Paul McGuire:
Thank you very much for these notes!
See also a few other notes:
Michael Foord:
http://www.voidspace.org.uk/python/weblog/arch_d7_2010_03_20.shtml#e1167
Ned Batchelder:
http://nedbatchelder.com/blog/200910/running_the_same_code_on_python_2x_and_3x.html
I was wondering if it
On Thu, Jul 8, 2010 at 5:41 AM, Zooko O'Whielacronx wrote:
> I'm starting to think that one should use Decimals by default and
> reserve floats for special cases.
>
> This is somewhat analogous to the way that Python provides
> arbitrarily-big integers by default and Python programmers only use
>
On 7/7/2010 9:14 PM, Ben Finney wrote:
The point, one more time with feeling, is that the incompatibilities
between 2.x and 3.x will *increase* over time.
For the purpose of maintaining least-common-denominator multi-version
code, it is only deletions and semantic changes that matter. Feature
On Wed, Jul 7, 2010 at 11:32 PM, Ben Finney wrote:
> geremy condra writes:
>
>> On Wed, Jul 7, 2010 at 9:14 PM, Ben Finney
>> wrote:
>> > [backward-]incompatibilities between 2.x and 3.x will *increase*
>> > over time.
>>
>> ...and? I don't get to use features from 2.7, why would I expect to
>>
Ben Finney writes:
>> On the other hand, the door appears closed for Python 3 adding more
>> stuff that breaks Python 2 code.
>
> What gives you that idea? Can you reference a specific statement from
> the PYthon developers that says that?
It's just logic. As I understand it, future versions of
On 7/7/2010 4:31 AM, Paul McGuire wrote:
[snip interesting report on how Paul suppost pyparsing for 2.3 to 3.1]
Thank you for this.
Do you think such cross-version support would have been easier or harder
if the major changes and deletions in 3.0 has been spread over several
versions, such as
On Wed, Jul 7, 2010 at 9:10 PM, Martin v. Loewis wrote:
>
> My preferred long-term solution is to reduce the usage of the C library
> in CPython as much as reasonable, atleast on Windows. Memory management
> could directly use the heap functions (or even more directly
> VirtualAlloc); filenos cou
I'm starting to think that one should use Decimals by default and
reserve floats for special cases.
This is somewhat analogous to the way that Python provides
arbitrarily-big integers by default and Python programmers only use
old-fashioned fixed-size integers for special cases, such as
interopera
geremy condra writes:
> On Wed, Jul 7, 2010 at 9:14 PM, Ben Finney wrote:
> > [backward-]incompatibilities between 2.x and 3.x will *increase*
> > over time.
>
> ...and? I don't get to use features from 2.7, why would I expect to
> use features from 3.3?
Conversely, why would you support Python
On 7/7/2010 5:29 AM, geremy condra wrote:
On Tue, Jul 6, 2010 at 1:37 AM, Terry Reedy wrote:
On 7/5/2010 9:00 PM, Philip Semanchuk wrote:
On Jul 5, 2010, at 6:41 PM, Chris Rebert wrote:
On Mon, Jul 5, 2010 at 3:38 PM, Philip Semanchu
I ported two pure C extensions from 2 to 3 and was even
The code below, very much work in progress, just trying things, is C++.
Sorry about the formatting, I had to reformat manually for this posting:
class Module
{
private:
Ptr p_;
public:
Module( PyModuleDef const& def )
: p_( ::PyModule_Create( co
On Wed, Jul 7, 2010 at 10:55 PM, Carl Banks wrote:
> On Jul 7, 1:31 am, Paul McGuire wrote:
>> On Jul 6, 3:30 am, David Cournapeau wrote:> On Tue, Jul
>> 6, 2010 at 4:30 AM, D'Arcy J.M. Cain wrote:
>>
>> > One thing that would be very useful is how to maintain something that
>> > works on 2.x
Paul Rubin writes:
> Ben Finney writes:
> > The point, one more time with feeling, is that the incompatibilities
> > between 2.x and 3.x will *increase* over time.
>
> The issue is less the "incompatibilities" than the -backwards-
> incompatibilities.
Yes, that's what I meant. Python 3 is delib
* Alf P. Steinbach /Usenet, on 08.07.2010 01:47:
enum DoAddRef { doAddRef };
class Ptr
{
private:
PyObject* p_;
public:
Ptr( PyObject* p = 0 ): p_( p )
{}
Ptr( PyObject* p, DoAddRef ): p_( p )
{
assert( p !=
On Wed, Jul 7, 2010 at 9:14 PM, Ben Finney wrote:
> geremy condra writes:
>
>> On Wed, Jul 7, 2010 at 8:26 PM, Brendan Abel <007bren...@gmail.com> wrote:
>> > Python 3.x will continue to change. The incompatibilities between
>> > 3.x and 2.x will only become more numerous. If your goal is to
>>
Ben Finney writes:
> The point, one more time with feeling, is that the incompatibilities
> between 2.x and 3.x will *increase* over time.
The issue is less the "incompatibilities" than the -backwards-
incompatibilities. Yes, Python 3 may introduce forward
incompatibilities by adding features ab
> I, too, have multiple versions installed -- newer ones for running code
> I haven't upgraded; older ones for compatibility testing where needed.
> I just install to the default c:\pythonxy directories (although I like
> the idea of a common root) and I put NTFS hardlinks into my general
> c:\too
On Jul 7, 2:10 pm, Brendan Abel <007bren...@gmail.com> wrote:
> > > > One thing that would be very useful is how to maintain something that
> > > > works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
> > > > versions below 2.6 is out of the question for most projects with a
> > > > si
On Jul 5, 1:34 am, sturlamolden wrote:
> On 5 Jul, 01:58, John Nagle wrote:
>
> > Exactly.
>
> > The "incompatible with all extension modules I need" part
> > is the problem right now. A good first step would be to
> > identify the top 5 or 10 modules that are blocking a move to
> > Py
geremy condra wrote:
On Wed, Jul 7, 2010 at 8:26 PM, Brendan Abel <007bren...@gmail.com> wrote:
On Jul 7, 3:00 pm, MRAB wrote:
Brendan Abel wrote:
One thing that would be very useful is how to maintain something that
works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
versions b
geremy condra writes:
> On Wed, Jul 7, 2010 at 8:26 PM, Brendan Abel <007bren...@gmail.com> wrote:
> > Python 3.x will continue to change. The incompatibilities between
> > 3.x and 2.x will only become more numerous. If your goal is to
> > support 2.x, and 3.x, you'd be best supporting them sep
We are pleased to announce the availability of ActivePython 2.7.0.1.
http://www.activestate.com/activepython
This release corresponds to the recently released Python 2.7, and, like
ActivePython 2.6, includes the Python Package Manager (PyPM) with
essential packages such as Distribute (a co
On Wed, Jul 7, 2010 at 8:26 PM, Brendan Abel <007bren...@gmail.com> wrote:
> On Jul 7, 3:00 pm, MRAB wrote:
>> Brendan Abel wrote:
>> One thing that would be very useful is how to maintain something that
>> works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
>> version
On Wed, Jul 7, 2010 at 3:48 PM, Nathan Huesken wrote:
> Hi,
>
> I have a class, where I want to store a callback function as a member
> to access later:
>
> class CallbackClass:
> def setCallback(self,cb):
> self.cb = cb
>
> def callCallback(self, para):
> self.cb(para)
>
> Doi
On Jul 7, 3:00 pm, MRAB wrote:
> Brendan Abel wrote:
> One thing that would be very useful is how to maintain something that
> works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
> versions below 2.6 is out of the question for most projects with a
> significant us
Yes, you SQL would be trivial to manipulate via SQL injection.
Not only do you need to validate each piece of data submitted by a user, you
need to escape all the wildcard characters that your database uses. If the text
string supplied by a user has quotes or parens or wildcard characters, the t
On Jul 6, 12:11 pm, Steven D'Aprano wrote:
> On Mon, 05 Jul 2010 21:12:47 -0700, kedra marbun wrote:
> > On Jul 5, 7:49 am, Gregory Ewing wrote:
> >> kedra marbun wrote:
> >> > now, i'm asking another favor, what about the 2nd point in my 1st
> >> > post?
>
> >> Your original post has dropped off
* rantingrick, on 07.07.2010 07:42:
On Jul 6, 9:11 pm, "Alf P. Steinbach /Usenet" wrote:
"pyni"! Pronounced like "tiny"! Yay!
hmm, how's about an alternate spelling... "pyknee", or "pynee", or
"pynie" ... considering those are not taken either?
Hm, for pure shock value I think I'll use the
> I'm working on street address parsing again,
> and I'm trying to deal with some of the harder cases.
>
For yet another test case
my actual address includes
... East South Mountain Avenue
Sometimes written as
... E. South Mtn Ave
--
Stanley C. Kitching
Human Bei
On Jul 7, 2:46 am, Bruno Desthuilliers
wrote:
> Gregory Ewing a écrit :
>
> > Bruno Desthuilliers wrote:
> >> kedra marbun a écrit :
>
> >>> if we limit our discussion to py:
> >>> why __{get|set|delete}__ don't receive the 'name' & 'class' from
> >>> __{getattribute|{set|del}attr}__
> >>> 'name'
Rami Chowdhury wrote:
On Tuesday 06 July 2010 22:42:25 rantingrick wrote:
On Jul 6, 9:11 pm, "Alf P. Steinbach /Usenet" wrote:
"pyni"! Pronounced like "tiny"! Yay!
hmm, how's about an alternate spelling... "pyknee", or "pynee", or
"pynie" ... considering those are not taken either?
Pynie's
On 7 Jul., 19:32, Ethan Furman wrote:
> Nobody wrote:
> > On Wed, 07 Jul 2010 15:08:07 +0200, Thomas Jollans wrote:
>
> >> you should never rely on a floating-point number to have exactly a
> >> certain value.
>
> > "Never" is an overstatement. There are situations where you can rely
> > upon a fl
On Tuesday 06 July 2010 22:42:25 rantingrick wrote:
> On Jul 6, 9:11 pm, "Alf P. Steinbach /Usenet"
> +use...@gmail.com> wrote:
> > "pyni"! Pronounced like "tiny"! Yay!
>
> hmm, how's about an alternate spelling... "pyknee", or "pynee", or
> "pynie" ... considering those are not taken either?
P
On 8 Jul, 00:35, Jonathan Hartley wrote:
> I see. Thanks very much to both of you for the info, much appreciated.
The problem you referred to for py2exe despaired with Python 2.6. For
Python 2.5, there was no public download option for msvcr71.dll and
msvcp71.dll. There was also the unsolved SxS
On Jul 7, 8:22 pm, "Martin v. Loewis" wrote:
> > I presume this problem would go away if future versions of Python
> > itself were compiled on Windows with something like MinGW gcc. Also,
> > this would solve the pain of Python developers attempting to
> > redistribute py2exe versions of their pro
On 7/7/2010 2:48 PM Nathan Huesken said...
class CallbackClass:
def setCallback(self,cb):
self.cb = cb
def callCallback(self, para):
self.cb(para)
You'll have to show how you're invoking this -- the following works for
me (ie, I don't get an error):
class Callb
On Wed, 07 Jul 2010 22:48:11 +0100, Nathan Huesken
wrote:
Hi,
I have a class, where I want to store a callback function as a member
to access later:
class CallbackClass:
def setCallback(self,cb):
self.cb = cb
def callCallback(self, para):
self.cb(para)
Doing so, I
On 2010-07-07, Grant Edwards wrote:
> I'm trying to use python bindings for libconfig. There appear to be
> three very slightly different bindings:
>
>http://code.google.com/p/python-libconfig/
>http://wiki.github.com/cnangel/python-libconfig/
>http://github.com/azeey/python-libconfi
John Nagle writes:
>Python 3 is a nice cleanup of some legacy syntax issues. But
> that's just not enough. Perl 6 is a nice cleanup of Perl 5,
Eh, I wouldn't call Perl 6 a "nice cleanup". It's much better to
consider it a new language with roots in Perl 5 (amongst others). Or
to quote from
Nathan Huesken wrote:
Hi,
I have a class, where I want to store a callback function as a member
to access later:
class CallbackClass:
def setCallback(self,cb):
self.cb = cb
def callCallback(self, para):
self.cb(para)
Doing so, I get the error:
callbackFunc() takes exac
I'm trying to use python bindings for libconfig. There appear to be
three very slightly different bindings:
http://code.google.com/p/python-libconfig/
http://wiki.github.com/cnangel/python-libconfig/
http://github.com/azeey/python-libconfig/
I'm using the latter with libconfig 1.4.5
On 7 Jul, 23:19, "Alf P. Steinbach /Usenet" wrote:
> D Linking the CRT dynamically and providing an optional download and
> install of the redistributables if they're not present. This would
> best be done with some support from the Python installation machinery.
> -> Small nice
Brendan Abel wrote:
One thing that would be very useful is how to maintain something that
works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
versions below 2.6 is out of the question for most projects with a
significant userbase IMHO. As such, the idea of running the python 3
warni
Am 07.07.2010 23:49, schrieb sturlamolden:
> On 7 Jul, 23:33, "Martin v. Loewis" wrote:
>
>>> The Windows API "errno" is GetLastError. But a delinquent CRT might
>>> map GetLastError() to other integers.
>>
>> Please check the source before posting. msvcrt defines errno as
>
> I don't have the s
On 7 Jul, 23:33, "Martin v. Loewis" wrote:
> > The Windows API "errno" is GetLastError. But a delinquent CRT might
> > map GetLastError() to other integers.
>
> Please check the source before posting. msvcrt defines errno as
I don't have the source to msvcrt, at least not to my knowledge.
--
Hi,
I have a class, where I want to store a callback function as a member
to access later:
class CallbackClass:
def setCallback(self,cb):
self.cb = cb
def callCallback(self, para):
self.cb(para)
Doing so, I get the error:
callbackFunc() takes exactly 1 parameter (2 given
* Alf P. Steinbach /Usenet, on 07.07.2010 23:19:
However developing an extension with MSVC 10 the extension will use the
10.0 CRT, which is not necessarily present on the end user's system.
As I see it there are five solutions with different trade-offs:
A Already having Visual Studio 2008 (MSV
Am 07.07.2010 22:35, schrieb sturlamolden:
> On 7 Jul, 22:26, Christian Heimes wrote:
>
>> Don't forget errno! Every CRT might have its own errno thread local. I
>> don't know how its handled on Windows but I suspect it suffers from the
>> same problem.
>
> The Windows API "errno" is GetLastErro
> Well, you could use an approach like the one suggested here:
>
> http://plumberjack.blogspot.com/2010/07/using-custom-formatter-to-dea...
That's nice, thanks. I'll use something like this. Just a thought : I
will use "errors=replace" in the call to the encode method to be sure
that the logger do
On 2010-07-07, Philip Semanchuk wrote:
>
> On Jul 6, 2010, at 3:16 PM, Tim Johnson wrote:
>
>> Greetings:
>> I would appreciate it if some could recommend a MySQLdb forum.
>
> The one associated the sourceforge project seems like a good bet.
>
> 1) go here: http://sourceforge.net/projects/mysql-py
* Christian Heimes, on 07.07.2010 22:47:
The main problem that the required MSVC redistributables are not necessarily
present on the end user's system.
It's not a problem for Python anymore. It took a while to sort all
problems out. Martin and other developers have successfully figured out
how
> > > One thing that would be very useful is how to maintain something that
> > > works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
> > > versions below 2.6 is out of the question for most projects with a
> > > significant userbase IMHO. As such, the idea of running the python 3
> >
"Democracy is sick in the US, government monitors your Internet"
http://www.youtube.com/watch?v=2BfCJq_zIdk&feature=fvsr
Enjoy .
--
http://mail.python.org/mailman/listinfo/python-list
"Democracy is sick in the US, government monitors your Internet"
http://www.youtube.com/watch?v=2BfCJq_zIdk&feature=fvsr
Enjoy .
--
http://mail.python.org/mailman/listinfo/python-list
On Jul 7, 1:31 am, Paul McGuire wrote:
> On Jul 6, 3:30 am, David Cournapeau wrote:> On Tue, Jul
> 6, 2010 at 4:30 AM, D'Arcy J.M. Cain wrote:
>
> > One thing that would be very useful is how to maintain something that
> > works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
> > ve
> The main problem that the required MSVC redistributables are not necessarily
> present on the end user's system.
It's not a problem for Python anymore. It took a while to sort all
problems out. Martin and other developers have successfully figured out
how to install the CRT for system wide and
On 7 Jul, 22:26, Christian Heimes wrote:
> Don't forget errno! Every CRT might have its own errno thread local. I
> don't know how its handled on Windows but I suspect it suffers from the
> same problem.
The Windows API "errno" is GetLastError. But a delinquent CRT might
map GetLastError() to ot
> Yeah, but then we're down to file descriptors, C library locales and such as
> the
> remaining problems.
Don't forget errno! Every CRT might have its own errno thread local. I
don't know how its handled on Windows but I suspect it suffers from the
same problem.
Christia
--
http://mail.pytho
On 2010-07-07, Martin v. Loewis wrote:
>
>> Also observe that this macro is very badly written (even illegal) C.
>> Consider what this would do:
>>
>> PyMem_MALLOC(n++)
>>
>> According to Linus Thorvalds using macros like this is not even legal
>> C:
>>
>> http://www.linuxfocus.org/common/s
On 7 Jul, 21:47, "Martin v. Loewis" wrote:
> However, the C standard is silent wrt. to PyMem_MALLOC, and it certainly
> allows the definition of macros which use the macro arguments more than
> once.
Ok, I knew there was something odd here. PyMem_Malloc is indeed a
function, whilst PyMem_MALLOC
On 07/07/2010 19:38, Victor Subervi wrote:
Hi;
I have this code:
sql = 'insert into personalDataKeys values (%s, %s, %s)' % (store,
user, ', %s'.join('%s' * len(col_vals))
cursor.execute(sql, col_vals)
Is this open to injection attacks? If so, how correct?
TIA,
beno
Yes, it is trivia
* Martin v. Loewis, on 07.07.2010 21:56:
Perhaps (if it isn't intentional) this is a bug of the oversight type,
that nobody remembered to update the macro?
Update in what way?
I was guessing that at one time there was no PyMem_Malloc. And that it
was introduced to fix Windows-specific problem
* sturlamolden, on 07.07.2010 21:46:
On 7 Jul, 21:41, "Alf P. Steinbach /Usenet" wrote:
You still have two CRTs linked into the same process.
So?
CRT resources cannot be shared across CRT borders. That is the
problem. Multiple CRTs are not a problem if CRT resources are never
shared.
Yea
>>> Perhaps (if it isn't intentional) this is a bug of the oversight type,
>>> that nobody remembered to update the macro?
>>
>> Update in what way?
>
> I was guessing that at one time there was no PyMem_Malloc. And that it
> was introduced to fix Windows-specific problems, but inadvertently
> wit
On 7 Jul, 21:47, "Martin v. Loewis" wrote:
> That would partially defeat the purpose, namely it would require the
> compiler to put the size into a variable in memory, and possibly prevent
> optimizations from taking place that rely on constant propagation
> (depending on how smart the compiler i
> Also observe that this macro is very badly written (even illegal) C.
> Consider what this would do:
>
> PyMem_MALLOC(n++)
>
> According to Linus Thorvalds using macros like this is not even legal
> C:
>
> http://www.linuxfocus.org/common/src/January2004_linus.html
[Please don't use "lega
On 7 Jul, 21:41, "Alf P. Steinbach /Usenet" wrote:
> > You still have two CRTs linked into the same process.
>
> So?
CRT resources cannot be shared across CRT borders. That is the
problem. Multiple CRTs are not a problem if CRT resources are never
shared.
--
http://mail.python.org/mailman/l
* sturlamolden, on 07.07.2010 21:12:
On 7 Jul, 06:54, "Alf P. Steinbach /Usenet" wrote:
PyAPI_FUNC(void *) PyMem_Malloc(size_t);
#define PyMem_MALLOC(n) (((n)< 0 || (n)> PY_SSIZE_T_MAX) ? NULL \
: malloc((n) ? (n) : 1))
I was afraid of that :(
* Martin v. Loewis, on 07.07.2010 21:10:
Python 3.1.1, file [pymem.h]:
PyAPI_FUNC(void *) PyMem_Malloc(size_t);
#define PyMem_MALLOC(n)(((n)< 0 || (n)> PY_SSIZE_T_MAX) ? NULL \
: malloc((n) ? (n) : 1))
The problem with the latter that it seems that it's intended for
On 7 Jul, 21:12, sturlamolden wrote:
> > #define PyMem_MALLOC(n) (((n) < 0 || (n) > PY_SSIZE_T_MAX) ? NULL \
> > : malloc((n) ? (n) : 1))
>
> I was afraid of that :(
Also observe that this macro is very badly written (even illegal) C.
Consider what this wo
Stephen Hansen wrote:
On 7/7/10 11:38 AM, Victor Subervi wrote:
Hi;
I have this code:
sql = 'insert into personalDataKeys values (%s, %s, %s)' % (store,
user, ', %s'.join('%s' * len(col_vals))
cursor.execute(sql, col_vals)
First, its always best to be explicit with insert statements.
> I presume this problem would go away if future versions of Python
> itself were compiled on Windows with something like MinGW gcc. Also,
> this would solve the pain of Python developers attempting to
> redistribute py2exe versions of their programs (i.e. they have to own
> a Visual Studio license
On 7 Jul, 06:54, "Alf P. Steinbach /Usenet" wrote:
> PyAPI_FUNC(void *) PyMem_Malloc(size_t);
>
> #define PyMem_MALLOC(n) (((n) < 0 || (n) > PY_SSIZE_T_MAX) ? NULL \
> : malloc((n) ? (n) : 1))
I was afraid of that :(
> Except for the problems with file
> Python 3.1.1, file [pymem.h]:
>
> PyAPI_FUNC(void *) PyMem_Malloc(size_t);
>
> #define PyMem_MALLOC(n)(((n) < 0 || (n) > PY_SSIZE_T_MAX) ? NULL \
> : malloc((n) ? (n) : 1))
>
> The problem with the latter that it seems that it's intended for safety
> but does the opposi
On 7 Jul, 11:32, Jonathan Hartley wrote:
> Also,
> this would solve the pain of Python developers attempting to
> redistribute py2exe versions of their programs (i.e. they have to own
> a Visual Studio license to legally be able to redistribute the
> required C runtime)
http://www.microsoft.com/d
On 7/7/10 11:38 AM, Victor Subervi wrote:
> Hi;
> I have this code:
>
> sql = 'insert into personalDataKeys values (%s, %s, %s)' % (store,
> user, ', %s'.join('%s' * len(col_vals))
> cursor.execute(sql, col_vals)
First, its always best to be explicit with insert statements. Meaning,
don't
Hi;
I have this code:
sql = 'insert into personalDataKeys values (%s, %s, %s)' % (store, user,
', %s'.join('%s' * len(col_vals))
cursor.execute(sql, col_vals)
Is this open to injection attacks? If so, how correct?
TIA,
beno
--
http://mail.python.org/mailman/listinfo/python-list
On Wed, Jul 7, 2010 at 8:31 AM, Michael Torrie wrote:
> On 07/06/2010 09:34 PM, Chris Rebert wrote:
>> On Tue, Jul 6, 2010 at 6:40 AM, Michael Torrie wrote:
>>> While it's possible to set up pipes and spawn programs in parallel to
>>> operate on the pipes, in practice it's simpler to tell subproc
On Jul 7, 5:55 am, Mark Dickinson wrote:
> On Jul 7, 1:05 pm, david mainzer wrote:
>
>
>
> > Dear Python-User,
>
> > today i create some slides about floating point arithmetic. I used an
> > example from
>
> >http://docs.python.org/tutorial/floatingpoint.html
>
> > so i start the python shell on
2010/7/7 durumdara :
> Hi!
>
> I have an environment under Python 2.6 (WinXP). That is based on PIL,
> wxPython/PyWin32.
>
> In the project's pages I see official installer for only PyWin32.
>
> I don't know that PIL or wxPython supports Python 3 or not. May with
> some trick these packages are wor
Nobody wrote:
On Wed, 07 Jul 2010 15:08:07 +0200, Thomas Jollans wrote:
you should never rely on a floating-point number to have exactly a
certain value.
"Never" is an overstatement. There are situations where you can rely
upon a floating-point number having exactly a certain value.
It's no
On 20 June, 03:48, Tim Rentsch wrote:
> nanothermite911fbibustards
> writes:
>
> Asking whether Lisp is faster than C is like asking why it's
> colder in the mountains than it is in the summer.
original Karl Valentin would be
but yours is in his sense.
Wolfgang
--
http://mail.python.org/mail
In article <5325a$4c349b5b$4275d90a$27...@fuse.net>,
Kevin Walzer wrote:
> That's decision for each business to make. My guess is that many
> businesses won't upgrade for some time, until the major
> libraries/modules support Python 3. I don't plan to move to Python 3 for
> at least a couple
On Jun 13, 4:07 pm, bolega wrote:
> I am trying to compare LISP/Scheme/Python for their expressiveness.
>
> For this, I propose a vanilla C interpreter. I have seen a book which
> writes C interpreter in C.
>
> The criteria would be the small size and high readability of the code.
>
> Are there al
On Wed, 07 Jul 2010 15:08:07 +0200, Thomas Jollans wrote:
> you should never rely on a floating-point number to have exactly a
> certain value.
"Never" is an overstatement. There are situations where you can rely
upon a floating-point number having exactly a certain value.
First, floating-point
> Depending on how far this goes up, you might just be able to change the
> backlog your terminal emulator saves? that would allow you to scroll up.
> If you can't do that, you should get a proper console.
>
I use bash, which allows to do that. This was rather a case example -
actually this output
On 07/06/2010 09:34 PM, Chris Rebert wrote:
> On Tue, Jul 6, 2010 at 6:40 AM, Michael Torrie wrote:
>> While it's possible to set up pipes and spawn programs in parallel to
>> operate on the pipes, in practice it's simpler to tell subprocess.Popen
>> to use a shell and then just rely on Bash's ver
1 - 100 of 126 matches
Mail list logo
