"Ian Kelly" wrote in message
news:calwzidk2+b5bym5b+xvtoz8lheyvhcos4v58f8z2o1jb6sa...@mail.gmail.com...
> On Tue, Jul 9, 2013 at 11:54 PM, Frank Millman wrote:
>> You had me worried there for a moment, as that is obviously an error.
>>
>> Then I checked my actual code, and I find that I mis-tra
On 07/09/2013 10:54 PM, Frank Millman wrote:
"Ian Kelly" wrote in message
news:calwzidnf3obe0enf3xthlj5a40k8hxvthveipecq8+34zxy...@mail.gmail.com...
On Tue, Jul 9, 2013 at 10:07 AM, Ethan Furman wrote:
You could also do it like this:
def updating(self):
self.transaction_active
On Tue, Jul 9, 2013 at 11:54 PM, Frank Millman wrote:
> You had me worried there for a moment, as that is obviously an error.
>
> Then I checked my actual code, and I find that I mis-transcribed it. It
> actually looks like this -
>
> with db_session as conn:
> db_session.transaction_a
"Ian Kelly" wrote in message
news:calwzidnf3obe0enf3xthlj5a40k8hxvthveipecq8+34zxy...@mail.gmail.com...
> On Tue, Jul 9, 2013 at 10:07 AM, Ethan Furman wrote:
>> You could also do it like this:
>>
>> def updating(self):
>> self.transaction_active = True
>> return self
>
> Ye
On 07/09/2013 11:41 AM, Ian Kelly wrote:
On Tue, Jul 9, 2013 at 11:23 AM, Ethan Furman wrote:
On 07/09/2013 09:44 AM, Ian Kelly wrote:
On Tue, Jul 9, 2013 at 10:07 AM, Ethan Furman wrote:
You could also do it like this:
def updating(self):
self.transaction_active = True
On Tue, Jul 9, 2013 at 11:23 AM, Ethan Furman wrote:
> On 07/09/2013 09:44 AM, Ian Kelly wrote:
>>
>> On Tue, Jul 9, 2013 at 10:07 AM, Ethan Furman wrote:
>>>
>>> You could also do it like this:
>>>
>>> def updating(self):
>>> self.transaction_active = True
>>> return self
On 07/09/2013 09:44 AM, Ian Kelly wrote:
On Tue, Jul 9, 2013 at 10:07 AM, Ethan Furman wrote:
You could also do it like this:
def updating(self):
self.transaction_active = True
return self
Yes, that would be simpler. I was all set to point out why this
doesn't work, a
On Tue, Jul 9, 2013 at 10:07 AM, Ethan Furman wrote:
> You could also do it like this:
>
> def updating(self):
> self.transaction_active = True
> return self
Yes, that would be simpler. I was all set to point out why this
doesn't work, and then I noticed that the location of
On 07/09/2013 01:38 AM, Frank Millman wrote:
"Ian Kelly" wrote in message
news:CALwzid=fzgjpebifx1stdbkh8iwltwggwwptphz1ykyg+05...@mail.gmail.com...
On Tue, Jul 9, 2013 at 1:35 AM, Frank Millman wrote:
When any of them need any database access, whether for reading or for
updating, they execu
"Ian Kelly" wrote in message
news:CALwzid=fzgjpebifx1stdbkh8iwltwggwwptphz1ykyg+05...@mail.gmail.com...
> On Tue, Jul 9, 2013 at 1:35 AM, Frank Millman wrote:
>> When any of them need any database access, whether for reading or for
>> updating, they execute the following -
>>
>> with db_ses
"Chris Angelico" wrote in message
news:captjjmr4mr0qcgwqxwyvdcz55nuav79vbtt8bjndsdvhrkq...@mail.gmail.com...
> On Tue, Jul 9, 2013 at 5:35 PM, Frank Millman wrote:
>> I have been following this sub-thread with interest, as it resonates with
>> what I am doing in my project.
>
> Just FYI, none o
On Tue, Jul 9, 2013 at 1:35 AM, Frank Millman wrote:
> When any of them need any database access, whether for reading or for
> updating, they execute the following -
>
> with db_session as conn:
> conn.transaction_active = True # this line must be added if
> updating
> conn.cu
On Tue, Jul 9, 2013 at 5:35 PM, Frank Millman wrote:
> I have been following this sub-thread with interest, as it resonates with
> what I am doing in my project.
Just FYI, none of my own code will help you as it's all using libpqxx,
but the docs for the library itself are around if you want them
"Chris Angelico" wrote in message
news:captjjmqkmfd4-jpugr-vubub6ribv6k_mwnxc_u3cvabr_w...@mail.gmail.com...
> On Tue, Jul 9, 2013 at 4:08 PM, alex23 wrote:
>> On 9/07/2013 3:07 PM, Chris Angelico wrote:
>>>
>>> The subtransactions are NOT concepted as separate transactions. They
>>> are effect
On Tue, Jul 9, 2013 at 4:08 PM, alex23 wrote:
> On 9/07/2013 3:07 PM, Chris Angelico wrote:
>>
>> The subtransactions are NOT concepted as separate transactions. They
>> are effectively the database equivalent of a try/except block.
>
>
> Sorry, I assumed each nested query was somehow related to t
On 9/07/2013 3:07 PM, Chris Angelico wrote:
The subtransactions are NOT concepted as separate transactions. They
are effectively the database equivalent of a try/except block.
Sorry, I assumed each nested query was somehow related to the prior
one. In which case, I'd probably go with Ethan's su
On Tue, Jul 9, 2013 at 2:52 PM, alex23 wrote:
> with new_transaction(conn) as folder_tran:
> folder_tran.query("blah")
> with folder_tran.subtransaction() as file_tran:
> file_tran.query("blah")
> with file_tran.subtransaction() as type_tran:
> type_tran.query("
On 7/07/2013 11:43 PM, Chris Angelico wrote:
Yep. There's a problem, though, when you bring in subtransactions. The
logic wants to be like this:
with new_transaction(conn) as tran:
tran.query("blah")
with tran.subtransaction() as tran:
tran.query("blah")
with tran.sub
On 4 July 2013 05:36, Chris Angelico wrote:
> On Thu, Jul 4, 2013 at 2:30 PM, Joshua Landau
> wrote:
>> That said, I'm not too convinced. Personally, the proper way to do
>> what you are talking about is creating a new closure. Like:
>>
>> for i in range(100):
>> with new_scope():
>>
On 8 July 2013 12:54, Neil Cerutti wrote:
> On 2013-07-07, Steven D'Aprano wrote:
>> On Fri, 05 Jul 2013 13:24:43 +, Neil Cerutti wrote:
>>
>>> for x in range(4):
>>>print(x)
>>> print(x) # Vader NOoOO!!!
>>
>> That loops do *not* introduce a new scope is a feature, not a bug. It
On 2013-07-07, Steven D'Aprano wrote:
> On Fri, 05 Jul 2013 13:24:43 +, Neil Cerutti wrote:
>
>> for x in range(4):
>>print(x)
>> print(x) # Vader NOoOO!!!
>
> That loops do *not* introduce a new scope is a feature, not a bug. It is
> *really* useful to be able to use the value of
On Mon, Jul 8, 2013 at 3:00 PM, Steven D'Aprano
wrote:
> On Mon, 08 Jul 2013 13:11:37 +1000, Chris Angelico wrote:
>> It's not something to be solved by the language, but it's often
>> something to be solved by the program's design. Two lines of code that
>> achieve the same goal should normally l
On Mon, 08 Jul 2013 13:11:37 +1000, Chris Angelico wrote:
> On Mon, Jul 8, 2013 at 12:23 PM, Steven D'Aprano
> wrote:
>> On Mon, 08 Jul 2013 10:48:03 +1000, Chris Angelico wrote: [...]
>>> That means that I, as programmer, have to keep track of the nesting
>>> level of subtransactions. Extremely
On Mon, Jul 8, 2013 at 12:23 PM, Steven D'Aprano
wrote:
> On Mon, 08 Jul 2013 10:48:03 +1000, Chris Angelico wrote:
> [...]
>> That means that I, as programmer, have to keep track of the nesting
>> level of subtransactions. Extremely ugly. A line of code can't be moved
>> around without first chec
On Mon, 08 Jul 2013 10:48:03 +1000, Chris Angelico wrote:
[...]
> That means that I, as programmer, have to keep track of the nesting
> level of subtransactions. Extremely ugly. A line of code can't be moved
> around without first checking which transaction object to work with.
I feel your pain, b
On Mon, Jul 8, 2013 at 2:52 AM, Ethan Furman wrote:
> On 07/07/2013 06:43 AM, Chris Angelico wrote:
>>
>> On Sun, Jul 7, 2013 at 11:13 PM, Wayne Werner
>> wrote:
>>>
>>> Which you would then use like:
>>>
>>>
>>> conn = create_conn()
>>> with new_transaction(conn) as tran:
>>> rows_affected
On Mon, Jul 8, 2013 at 2:03 AM, Steven D'Aprano
wrote:
> If you need more than two levels, you probably ought to re-design your
> code to be less confusing, otherwise you may be able to use ChainMap to
> emulate any number of nested scopes.
The subtransactions are primarily to represent the datab
On 07/07/2013 06:43 AM, Chris Angelico wrote:
The 'with' statement doesn't allow this. I would need to use some kind
of magic to rebind the old transaction to the name, or else use a list
that gets magically populated:
with new_transaction(conn) as tran:
tran[-1].query("blah")
with su
On 07/07/2013 06:43 AM, Chris Angelico wrote:
On Sun, Jul 7, 2013 at 11:13 PM, Wayne Werner wrote:
Which you would then use like:
conn = create_conn()
with new_transaction(conn) as tran:
rows_affected = do_query_stuff(tran)
if rows_affected == 42:
tran.commit()
Yep. T
On Fri, 05 Jul 2013 13:24:43 +, Neil Cerutti wrote:
> for x in range(4):
>print(x)
> print(x) # Vader NOoOO!!!
That loops do *not* introduce a new scope is a feature, not a bug. It is
*really* useful to be able to use the value of x after the loop has
finished. That's a much mor
On Sun, 07 Jul 2013 23:43:24 +1000, Chris Angelico wrote:
> On Sun, Jul 7, 2013 at 11:13 PM, Wayne Werner
> wrote:
>> Which you would then use like:
>>
>>
>> conn = create_conn()
>> with new_transaction(conn) as tran:
>> rows_affected = do_query_stuff(tran)
>> if rows_affected == 42:
>>
On Sun, Jul 7, 2013 at 11:13 PM, Wayne Werner wrote:
> Which you would then use like:
>
>
> conn = create_conn()
> with new_transaction(conn) as tran:
> rows_affected = do_query_stuff(tran)
> if rows_affected == 42:
> tran.commit()
Yep. There's a problem, though, when you brin
On Fri, 5 Jul 2013, Chris Angelico wrote:
Oh. Uhm... ahh... it would have helped to mention that it also has a
commit() method! But yes, that's correct; if the object expires (this
is C++, so it's guaranteed to call the destructor at that close brace
- none of the Python vagueness about when __d
On 2013-07-05, Chris Angelico wrote:
> On Fri, Jul 5, 2013 at 11:24 PM, Neil Cerutti
> wrote:
>> Python provides deterministic destruction with a different
>> feature.
>
> You mean 'with'? That's not actually destruction, it just does
> one of the same jobs that deterministic destruction is used
On Fri, Jul 5, 2013 at 11:24 PM, Neil Cerutti wrote:
> Python provides deterministic destruction with a different
> feature.
You mean 'with'? That's not actually destruction, it just does one of
the same jobs that deterministic destruction is used for (RAII). It
doesn't, for instance, have any in
On 2013-07-04, Dave Angel wrote:
> On 07/04/2013 01:32 AM, Steven D'Aprano wrote:
>
>> Well, if I ever have more than 63,000,000 variables[1] in a
>> function, I'll keep that in mind.
>>
>
>>
>> [1] Based on empirical evidence that Python supports names
>> with length at least up to
On 05/07/2013 02:24, Steven D'Aprano wrote:
On Thu, 04 Jul 2013 17:54:20 +0100, Rotwang wrote:
[...]
Anyway, none of the calculations that has been given takes into account
the fact that names can be /less/ than one million characters long.
Not in *my* code they don't!!!
*wink*
The
actual
On 5 July 2013 03:03, Dave Angel wrote:
> In particular,
> http://docs.python.org/3.3/reference/lexical_analysis.html#identifiers
>
> has a definition for id_continue that includes several interesting
> categories. I expected the non-ASCII digits, but there's other stuff there,
> like "nonsp
On 5 July 2013 03:03, Dave Angel wrote:
> On 07/04/2013 09:24 PM, Steven D'Aprano wrote:
>> On Thu, 04 Jul 2013 17:54:20 +0100, Rotwang wrote:
>>> It's perhaps worth mentioning that some non-ascii characters are allowed
>>> in identifiers in Python 3, though I don't know which ones.
>>
>> PEP 3131
On 07/04/2013 09:24 PM, Steven D'Aprano wrote:
On Thu, 04 Jul 2013 17:54:20 +0100, Rotwang wrote:
[...]
Anyway, none of the calculations that has been given takes into account
the fact that names can be /less/ than one million characters long.
Not in *my* code they don't!!!
*wink*
The
act
On Thu, 04 Jul 2013 17:54:20 +0100, Rotwang wrote:
[...]
> Anyway, none of the calculations that has been given takes into account
> the fact that names can be /less/ than one million characters long.
Not in *my* code they don't!!!
*wink*
> The
> actual number of non-empty strings of length a
On 4 July 2013 17:54, Rotwang wrote:
> 53*(63**100 - 1)//62
Or about 10**10**6.255 (so about 1.80M digits long).
For the unicode side (Python 3, in other words) and reusing your math
(ya better hope it's right!), you are talking:
97812*((97812+2020)**100 - 1)/(97812+2020-1)
Or about 1
Rotwang wrote:
> Sorry to be OT, but this is sending my pedantry glands haywire:
We are mostly pedants, too -- so this is well-deserved...
> On 04/07/2013 08:06, Dave Angel wrote:
>> On 07/04/2013 01:32 AM, Steven D'Aprano wrote:
>>>
>>
>>>
>>> Well, if I ever have more than 63,000,000
On Fri, Jul 5, 2013 at 2:38 AM, Steven D'Aprano
wrote:
> On Thu, 04 Jul 2013 15:47:57 +1000, Chris Angelico wrote:
>> Here's one example of shadowing that comes from a C++ project at work. I
>> have a class that represents a database transaction (constructing it
>> begins a transaction, it has met
Sorry to be OT, but this is sending my pedantry glands haywire:
On 04/07/2013 08:06, Dave Angel wrote:
On 07/04/2013 01:32 AM, Steven D'Aprano wrote:
Well, if I ever have more than 63,000,000 variables[1] in a function,
I'll keep that in mind.
[1] Based on empirical eviden
On Thu, 04 Jul 2013 15:47:57 +1000, Chris Angelico wrote:
> On Thu, Jul 4, 2013 at 3:32 PM, Steven D'Aprano
> wrote:
>> Accidental shadowing can be a problem, but I've never heard of anyone
>> saying that they were *forced* to shadow a global they needed access
>> to. Just pick a different name.
On Thu, 04 Jul 2013 03:06:25 -0400, Dave Angel wrote:
> On 07/04/2013 01:32 AM, Steven D'Aprano wrote:
>>
>
>>
>> Well, if I ever have more than 63,000,000 variables[1] in a function,
>> I'll keep that in mind.
>>
>
>>
>> [1] Based on empirical evidence that Python supports names wit
On Thu, 4 Jul 2013, Steven D'Aprano wrote:
[1] Based on empirical evidence that Python supports names with length at
least up to one million characters long, and assuming that each character
can be an ASCII letter, digit or underscore.
The specification *does* state unlimited length:
http://
Dave Angel writes:
> Well, the number wouldn't be 63,000,000. Rather it'd be 63**100
Uhm, if we are talking about Py2, then you should not count all the
combinations starting with a digit, while under Py3 the number explodes,
as this is valid code:
>>> à = 1
>>> à
1
:-)
back to easily-en
On 07/04/2013 01:32 AM, Steven D'Aprano wrote:
Well, if I ever have more than 63,000,000 variables[1] in a function,
I'll keep that in mind.
[1] Based on empirical evidence that Python supports names with length at
least up to one million characters long, and assuming that eac
On Wed, Jul 3, 2013 at 11:32 PM, Steven D'Aprano
wrote:
>> Python lets you do that across but not within functions.
>>
>> But Javascript/ECMAScript/whatever doesn't give you that. A var
>> declaration makes it function-local, no matter where the declaration is.
>> That's pointless. C++, on the oth
Steven D'Aprano wrote:
> Well, if I ever have more than 63,000,000 variables[1] in a function,
> I'll keep that in mind. Until then, I'm pretty sure you can trivially
> avoid name clashes with globals that you wish to avoid clashing with.
> [1] Based on empirical evidence that Python supports nam
On Thu, 04 Jul 2013 05:30:03 +0100, Joshua Landau wrote:
> That said, I'm not too convinced. Personally, the proper way to do what
> you are talking about is creating a new closure. Like:
>
> for i in range(100):
> with new_scope():
> for i in range(100):
> func(i)
> f
On Thu, Jul 4, 2013 at 3:32 PM, Steven D'Aprano
wrote:
> Accidental shadowing can be a problem, but I've never heard of anyone
> saying that they were *forced* to shadow a global they needed access to.
> Just pick a different name.
Here's one example of shadowing that comes from a C++ project at
On Thu, 04 Jul 2013 14:07:55 +1000, Chris Angelico wrote:
> On Thu, Jul 4, 2013 at 1:27 PM, Steven D'Aprano
> wrote:
>> With respect to the Huffman coding of declarations, Javascript gets it
>> backwards. Locals ought to be more common, but they require more
>> typing. Locals are safer, better, m
On 4 July 2013 05:36, Chris Angelico wrote:
> On Thu, Jul 4, 2013 at 2:30 PM, Joshua Landau
> wrote:
>> That said, I'm not too convinced. Personally, the proper way to do
>> what you are talking about is creating a new closure. Like:
>>
>> for i in range(100):
>> with new_scope():
>>
On Thu, Jul 4, 2013 at 2:30 PM, Joshua Landau
wrote:
> That said, I'm not too convinced. Personally, the proper way to do
> what you are talking about is creating a new closure. Like:
>
> for i in range(100):
> with new_scope():
> for i in range(100):
> func(i)
> func(i
On 4 July 2013 05:07, Chris Angelico wrote:
> On Thu, Jul 4, 2013 at 1:27 PM, Steven D'Aprano
> wrote:
>> With respect to the Huffman coding of declarations, Javascript gets it
>> backwards. Locals ought to be more common, but they require more typing.
>> Locals are safer, better, more desirable
On Thu, Jul 4, 2013 at 1:27 PM, Steven D'Aprano
wrote:
> With respect to the Huffman coding of declarations, Javascript gets it
> backwards. Locals ought to be more common, but they require more typing.
> Locals are safer, better, more desirable than globals, and so it should
> be easier to use lo
Recently, there was a thread where people discussed variable
declarations, with a couple people stating that they wished that Python
required you to declare local variables, instead of globals.
I'm sure they have their (foolish, pathetic) *wink* reasons for this, but
I thought I'd explain why I
thank you
--
http://mail.python.org/mailman/listinfo/python-list
Gary Wessle wrote:
> Ryan Forsythe <[EMAIL PROTECTED]> writes:
>
>
>>Gary Wessle wrote:
>>
>>>the example was an in-accuretlly representation of a the problem I am
>>>having. my apologies.
>>>
(snip)
> I finally was able to duplicate the error with a through away code
> as follows,
>
>
Ryan Forsythe <[EMAIL PROTECTED]> writes:
> Gary Wessle wrote:
> > the example was an in-accuretlly representation of a the problem I am
> > having. my apologies.
> >
> > a = []
> > def prnt():
> >print len(a)
> >
> prnt
> >
> >
> > I expect to get 0 "the length of list a"
>
> You wa
> is the code below correct?
>
> b = 3
> def adding(a)
> print a + b
>
> it seams not to see the up-level scope where b is defined.
Yes except for the missing : at the end of the "def" line.
Rob
--
http://mail.python.org/mailman/listinfo/python-list
Gary Wessle wrote:
> the example was an in-accuretlly representation of a the problem I am
> having. my apologies.
>
> a = []
> def prnt():
>print len(a)
>
prnt
>
>
> I expect to get 0 "the length of list a"
You want prnt(), not prnt:
>>> a = []
>>> def prnt():
... print len(a)
...
Gary Wessle wrote:
> the example was an in-accuretlly representation of a the problem I am
> having. my apologies.
>
> a = []
> def prnt():
>print len(a)
>
prnt
>
>
> I expect to get 0 "the length of list a"
Python requires parenthesis to call a function.
>>> a = []
>>> def prnt(
Try >>> prnt()
o.o'
On 04 May 2006 08:25:01 +1000, Gary Wessle <[EMAIL PROTECTED]> wrote:
> "Steve R. Hastings" <[EMAIL PROTECTED]> writes:
>
> > On Thu, 04 May 2006 07:02:43 +1000, Gary Wessle wrote:
> > > b = 3
> > > def adding(a)
> > > print a + b
> > >
> > > it seams not to see the up-leve
"Steve R. Hastings" <[EMAIL PROTECTED]> writes:
> On Thu, 04 May 2006 07:02:43 +1000, Gary Wessle wrote:
> > b = 3
> > def adding(a)
> > print a + b
> >
> > it seams not to see the up-level scope where b is defined.
>
> Assuming you put a ':' after the "def adding(a)", this should work in
>
Gary Wessle <[EMAIL PROTECTED]> writes:
> is the code below correct?
It's best to post an example that you've tried yourself, and that is
small but completely demonstrates the issue in question.
> b = 3
> def adding(a)
> print a + b
This, for example, would fail the syntax check (the 'def'
On Thu, 04 May 2006 07:02:43 +1000, Gary Wessle wrote:
> b = 3
> def adding(a)
> print a + b
>
> it seams not to see the up-level scope where b is defined.
Assuming you put a ':' after the "def adding(a)", this should work in
recent versions of Python. In Python 2.0 and older, this will not
In <[EMAIL PROTECTED]>, Gary Wessle wrote:
> is the code below correct?
No...
> b = 3
> def adding(a)
...a colon is missing at the end of the above line.
> print a + b
>
> it seams not to see the up-level scope where b is defined.
It does. And you could easily find out yourself by just
Hi
is the code below correct?
b = 3
def adding(a)
print a + b
it seams not to see the up-level scope where b is defined.
thanks
--
http://mail.python.org/mailman/listinfo/python-list
"Sandro Dentella" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I'd like to understand why += operator raises an error while .append()
> does
> not.
Your mistake is thinking of '+=' as an operator. In Python terms it is
not, any more than '=' is. In Python, neither 'a=b' nor
Duncan Booth wrote:
> Sandro Dentella wrote:
>
>> I'd like to understand why += operator raises an error while .append()
>> does not. My wild guess is the parses treats them differently but I
>> cannot understand why this depends on scope of the variables (global
>> or class variables):
>
>
>
Sandro Dentella wrote:
> I'd like to understand why += operator raises an error while .append()
> does not. My wild guess is the parses treats them differently but I
> cannot understand why this depends on scope of the variables (global
> or class variables):
>
>
> a = [0]
>
> class foo(object)
Em Dom, 2006-03-05 às 11:49 +, Sandro Dentella escreveu:
> class foo(object):
>
> def __init__(self):
> print "a: ", a
> # += does not work if 'a' is global
> #a += [1]
> a.append(2)
> print "a= ", a
Try with:
a = [0]
class foo(object):
def
I'd like to understand why += operator raises an error while .append() does
not. My wild guess is the parses treats them differently but I cannot
understand why this depends on scope of the variables (global or class
variables):
a = [0]
class foo(object):
def __init__(self):
print
77 matches
Mail list logo
