I have a CherryPy app, for which I am using a PostgreSQL session. To be more
exact, I modified a MySQL session class I found to work with PostgreSQL
instead, and then I put this line in my code:
cherrypy.lib.sessions.PostgresqlSession = PostgreSQLSession
And this works fine. One thing about its
On Thu, 14 May 2015 06:33 am, Ned Batchelder wrote:
> On Wednesday, May 13, 2015 at 3:46:16 PM UTC-4, Mark Lawrence wrote:
>> On 13/05/2015 19:42, andrew cooke wrote:
>> > On Wednesday, 13 May 2015 13:37:23 UTC-3, Terry Reedy wrote:
>> >> On 5/13/2015 9:25 AM, andrew cooke wrote:
[...]
>> >> >
On Wednesday, May 13, 2015 at 3:46:16 PM UTC-4, Mark Lawrence wrote:
> On 13/05/2015 19:42, andrew cooke wrote:
> > On Wednesday, 13 May 2015 13:37:23 UTC-3, Terry Reedy wrote:
> >> On 5/13/2015 9:25 AM, andrew cooke wrote:
> >>
> >>> The following code worked on Python 3.2, but no longer works in
On 13/05/2015 19:42, andrew cooke wrote:
On Wednesday, 13 May 2015 13:37:23 UTC-3, Terry Reedy wrote:
On 5/13/2015 9:25 AM, andrew cooke wrote:
The following code worked on Python 3.2, but no longer works in 3.4.
Bugfixes break code that depends on buggy behavior. See
https://bugs.python.or
On 5/13/2015 2:42 PM, andrew cooke wrote:
On Wednesday, 13 May 2015 13:37:23 UTC-3, Terry Reedy wrote:
On 5/13/2015 9:25 AM, andrew cooke wrote:
The following code worked on Python 3.2, but no longer works in 3.4.
Bugfixes break code that depends on buggy behavior. See
https://bugs.python.o
On Wednesday, 13 May 2015 13:37:23 UTC-3, Terry Reedy wrote:
> On 5/13/2015 9:25 AM, andrew cooke wrote:
>
> > The following code worked on Python 3.2, but no longer works in 3.4.
>
> Bugfixes break code that depends on buggy behavior. See
> https://bugs.python.org/issue1683368
> Your code also
On 13/05/2015 18:05, Terry Reedy wrote:
On 5/13/2015 12:38 PM, Mark Lawrence wrote:
I'm completely convinced that I've seen a change go through on the bug
tracker that impacts on this area, but many months if not years ago.
Unfortunately searching the bug tracker for super, __new__, __init__ an
On 5/13/2015 12:36 PM, Terry Reedy wrote:
On 5/13/2015 9:25 AM, andrew cooke wrote:
The following code worked on Python 3.2, but no longer works in 3.4.
Bugfixes break code that depends on buggy behavior. See
https://bugs.python.org/issue1683368
Your code also fails in 2.7.9 if you inherit Fo
On 5/13/2015 12:38 PM, Mark Lawrence wrote:
I'm completely convinced that I've seen a change go through on the bug
tracker that impacts on this area, but many months if not years ago.
Unfortunately searching the bug tracker for super, __new__, __init__ and
so on gets a lot of hits, leaving my Mk
On 13/05/2015 14:25, andrew cooke wrote:
Hi,
The following code worked on Python 3.2, but no longer works in 3.4. Did
something change, or have I always been doing something dumb?
(I realise the code is pointless as is - it's the simplest example I can give
of a problem I am seeing with mor
On 5/13/2015 9:25 AM, andrew cooke wrote:
The following code worked on Python 3.2, but no longer works in 3.4.
Bugfixes break code that depends on buggy behavior. See
https://bugs.python.org/issue1683368
Your code also fails in 2.7.9 if you inherit Foo from object.
The exact error messages cha
On Wednesday, 13 May 2015 11:56:21 UTC-3, Ian wrote:
> On Wed, May 13, 2015 at 8:45 AM, andrew cooke wrote:
> class Foo:
> > ... def __new__(cls, *args, **kargs):
> > ... print('new', args, kargs)
> > ... super().__new__(cls)
> > ...
> class Bar(Foo):
> > ... def
On Wed, May 13, 2015 at 8:45 AM, andrew cooke wrote:
class Foo:
> ... def __new__(cls, *args, **kargs):
> ... print('new', args, kargs)
> ... super().__new__(cls)
> ...
class Bar(Foo):
> ... def __init__(self, a):
> ... print('init', a)
> ...
Bar(1)
>
On Wed, May 13, 2015 at 8:42 AM, andrew cooke wrote:
> On Wednesday, 13 May 2015 11:36:12 UTC-3, Thomas Rachel wrote:
>> Am 13.05.2015 um 15:25 schrieb andrew cooke:
>>
>> class Foo:
>> > ... def __new__(cls, *args, **kargs):
>> > ... print('new', args, kargs)
>> > ... su
andrew cooke wrote:
>> But then nothing will be passed to __init__ on the subclass.
>>
>> Andrew
>
class Foo:
> ... def __new__(cls, *args, **kargs):
> ... print('new', args, kargs)
> ... super().__new__(cls)
> ...
class Bar(Foo):
> ... def __init__(self, a):
>
> But then nothing will be passed to __init__ on the subclass.
>
> Andrew
>>> class Foo:
... def __new__(cls, *args, **kargs):
... print('new', args, kargs)
... super().__new__(cls)
...
>>> class Bar(Foo):
... def __init__(self, a):
... print('init', a)
...
>>> B
On Wednesday, 13 May 2015 11:36:12 UTC-3, Thomas Rachel wrote:
> Am 13.05.2015 um 15:25 schrieb andrew cooke:
>
> class Foo:
> > ... def __new__(cls, *args, **kargs):
> > ... print('new', args, kargs)
> > ... super().__new__(cls, *args, **kargs)
>
> > new (1,) {}
> > Tra
Am 13.05.2015 um 15:25 schrieb andrew cooke:
class Foo:
... def __new__(cls, *args, **kargs):
... print('new', args, kargs)
... super().__new__(cls, *args, **kargs)
new (1,) {}
Traceback (most recent call last):
File "", line 1, in
File "", line 4, in __new__
TypeE
Hi,
The following code worked on Python 3.2, but no longer works in 3.4. Did
something change, or have I always been doing something dumb?
(I realise the code is pointless as is - it's the simplest example I can give
of a problem I am seeing with more complex code).
>>> class Foo:
... de
On Jan 28, 10:06 am, Bruno Desthuilliers wrote:
> perfr...@gmail.com a écrit :
>
>
>
> > hi,
>
> > i am doing a series of very simple string operations on lines i am
> > reading from a large file (~15 million lines). i store the result of
> > these operations in a simple instance of a class, and t
perfr...@gmail.com a écrit :
hi,
i am doing a series of very simple string operations on lines i am
reading from a large file (~15 million lines). i store the result of
these operations in a simple instance of a class, and then put it
inside of a hash table. i found that this is unusually slow..
hi,
i am doing a series of very simple string operations on lines i am
reading from a large file (~15 million lines). i store the result of
these operations in a simple instance of a class, and then put it
inside of a hash table. i found that this is unusually slow... for
example:
class myclass(o
On Fri, Nov 14, 2008 at 6:38 PM, Joe Strout <[EMAIL PROTECTED]> wrote:
> On Nov 14, 2008, at 4:33 PM, Jerry Hill wrote:
>
>> Then add
>> def __init__(self):
>> a = 0
>> b = 0
>
> Doesn't that have to be "self.a" and "self.b"?
Yes, that should indeed have been self.a and self.b! Sorry about that
On Fri, 14 Nov 2008 16:38:15 -0700, Joe Strout wrote:
> On Nov 14, 2008, at 4:33 PM, Jerry Hill wrote:
>
>> Then add
>> def __init__(self):
>> a = 0
>> b = 0
>>
>> to your box class to make a and b instance variables.
>
> Doesn't that have to be "self.a" and "self.b"?
Only if you want it to
BiraRai a écrit :
(snip)
class box:
a = int()
b = int()
I strongly suggest you read the tutorial.
--
http://mail.python.org/mailman/listinfo/python-list
BiraRai a écrit :
for record in roll:
x = box()
x.createSomething(record)
do something
Can anyone tell me why python keeps return the original object x that
was created in the FOR loop.
Where is the "return" statement ?
I want to instantiate a new x object for
each iterat
Jerry Hill a écrit :
On Fri, Nov 14, 2008 at 6:10 PM, BiraRai <[EMAIL PROTECTED]> wrote:
class box:
a = int()
b = int()
def createSomething(self,x):
At a guess, x = box() does create a new instance of your box class,
but since you've declared a and b to be class variables instead of
inst
On Nov 14, 2008, at 4:33 PM, Jerry Hill wrote:
Then add
def __init__(self):
a = 0
b = 0
to your box class to make a and b instance variables.
Doesn't that have to be "self.a" and "self.b"?
Best,
- Joe
--
http://mail.python.org/mailman/listinfo/python-list
On Fri, Nov 14, 2008 at 6:10 PM, BiraRai <[EMAIL PROTECTED]> wrote:
> class box:
> a = int()
> b = int()
>
> def createSomething(self,x):
At a guess, x = box() does create a new instance of your box class,
but since you've declared a and b to be class variables instead of
instance variables,
On Nov 14, 5:44 pm, George Sakkis <[EMAIL PROTECTED]> wrote:
> On Nov 14, 5:16 pm, BiraRai <[EMAIL PROTECTED]> wrote:
>
> > for record in roll:
> > x = box()
> > x.createSomething(record)
> > do something
>
> > Can anyone tell me why python keeps return the original object x that
>
On Nov 14, 5:16 pm, BiraRai <[EMAIL PROTECTED]> wrote:
> for record in roll:
> x = box()
> x.createSomething(record)
> do something
>
> Can anyone tell me why python keeps return the original object x that
> was created in the FOR loop. I want to instantiate a new x object for
> e
for record in roll:
x = box()
x.createSomething(record)
do something
Can anyone tell me why python keeps return the original object x that
was created in the FOR loop. I want to instantiate a new x object for
each iteration of the FOR loop
--
http://mail.python.org/mailman/list
On 2006-01-31, bruno at modulix <[EMAIL PROTECTED]> wrote:
> See other answers in this thread for how to solve the UnboundLocalError
> problem.
>
> Now about your *real* problem - which is nothing new -, you may want to
> read about some known solutions:
>
> http://en.wikipedia.org/wiki/Singleton_p
Charles Krug wrote:
> List:
>
> I've a module that's not doing what I expect. My guess is that I don't
> quite understand the scoping rules the way I should.
>
> I have an object that's costly to create. My thought was to create it
> at the module level like this:
(snip)
> What's the correct
34 matches
Mail list logo
