On Tue, Jul 9, 2013 at 11:54 PM, Frank Millman fr...@chagford.com 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:
On 07/09/2013 10:54 PM, Frank Millman wrote:
Ian Kelly ian.g.ke...@gmail.com wrote in message
news:calwzidnf3obe0enf3xthlj5a40k8hxvthveipecq8+34zxy...@mail.gmail.com...
On Tue, Jul 9, 2013 at 10:07 AM, Ethan Furman et...@stoneleaf.us wrote:
You could also do it like this:
def
Ian Kelly ian.g.ke...@gmail.com wrote in message
news:calwzidk2+b5bym5b+xvtoz8lheyvhcos4v58f8z2o1jb6sa...@mail.gmail.com...
On Tue, Jul 9, 2013 at 11:54 PM, Frank Millman fr...@chagford.com wrote:
You had me worried there for a moment, as that is obviously an error.
Then I checked my actual
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
On Tue, Jul 9, 2013 at 4:08 PM, alex23 wuwe...@gmail.com 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
Chris Angelico ros...@gmail.com wrote in message
news:captjjmqkmfd4-jpugr-vubub6ribv6k_mwnxc_u3cvabr_w...@mail.gmail.com...
On Tue, Jul 9, 2013 at 4:08 PM, alex23 wuwe...@gmail.com wrote:
On 9/07/2013 3:07 PM, Chris Angelico wrote:
The subtransactions are NOT concepted as separate
On Tue, Jul 9, 2013 at 5:35 PM, Frank Millman fr...@chagford.com 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
On Tue, Jul 9, 2013 at 1:35 AM, Frank Millman fr...@chagford.com 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
Chris Angelico ros...@gmail.com wrote in message
news:captjjmr4mr0qcgwqxwyvdcz55nuav79vbtt8bjndsdvhrkq...@mail.gmail.com...
On Tue, Jul 9, 2013 at 5:35 PM, Frank Millman fr...@chagford.com wrote:
I have been following this sub-thread with interest, as it resonates with
what I am doing in my
Ian Kelly ian.g.ke...@gmail.com wrote in message
news:CALwzid=fzgjpebifx1stdbkh8iwltwggwwptphz1ykyg+05...@mail.gmail.com...
On Tue, Jul 9, 2013 at 1:35 AM, Frank Millman fr...@chagford.com wrote:
When any of them need any database access, whether for reading or for
updating, they execute the
On 07/09/2013 01:38 AM, Frank Millman wrote:
Ian Kelly ian.g.ke...@gmail.com wrote in message
news:CALwzid=fzgjpebifx1stdbkh8iwltwggwwptphz1ykyg+05...@mail.gmail.com...
On Tue, Jul 9, 2013 at 1:35 AM, Frank Millman fr...@chagford.com wrote:
When any of them need any database access, whether
On Tue, Jul 9, 2013 at 10:07 AM, Ethan Furman et...@stoneleaf.us 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
On 07/09/2013 09:44 AM, Ian Kelly wrote:
On Tue, Jul 9, 2013 at 10:07 AM, Ethan Furman et...@stoneleaf.us 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
On Tue, Jul 9, 2013 at 11:23 AM, Ethan Furman et...@stoneleaf.us wrote:
On 07/09/2013 09:44 AM, Ian Kelly wrote:
On Tue, Jul 9, 2013 at 10:07 AM, Ethan Furman et...@stoneleaf.us wrote:
You could also do it like this:
def updating(self):
self.transaction_active = True
On 07/09/2013 11:41 AM, Ian Kelly wrote:
On Tue, Jul 9, 2013 at 11:23 AM, Ethan Furman et...@stoneleaf.us wrote:
On 07/09/2013 09:44 AM, Ian Kelly wrote:
On Tue, Jul 9, 2013 at 10:07 AM, Ethan Furman et...@stoneleaf.us wrote:
You could also do it like this:
def updating(self):
Ian Kelly ian.g.ke...@gmail.com wrote in message
news:calwzidnf3obe0enf3xthlj5a40k8hxvthveipecq8+34zxy...@mail.gmail.com...
On Tue, Jul 9, 2013 at 10:07 AM, Ethan Furman et...@stoneleaf.us wrote:
You could also do it like this:
def updating(self):
self.transaction_active = True
On 2013-07-07, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
On 8 July 2013 12:54, Neil Cerutti ne...@norwich.edu wrote:
On 2013-07-07, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
On 4 July 2013 05:36, Chris Angelico ros...@gmail.com wrote:
On Thu, Jul 4, 2013 at 2:30 PM, Joshua Landau
joshua.landau...@gmail.com 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):
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
On Tue, Jul 9, 2013 at 2:52 PM, alex23 wuwe...@gmail.com 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:
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
On Sun, Jul 7, 2013 at 11:13 PM, Wayne Werner wa...@waynewerner.com 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,
On Sun, 07 Jul 2013 23:43:24 +1000, Chris Angelico wrote:
On Sun, Jul 7, 2013 at 11:13 PM, Wayne Werner wa...@waynewerner.com
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 ==
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 more
On 07/07/2013 06:43 AM, Chris Angelico wrote:
On Sun, Jul 7, 2013 at 11:13 PM, Wayne Werner wa...@waynewerner.com 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 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
On Mon, Jul 8, 2013 at 2:03 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
On Mon, Jul 8, 2013 at 2:52 AM, Ethan Furman et...@stoneleaf.us wrote:
On 07/07/2013 06:43 AM, Chris Angelico wrote:
On Sun, Jul 7, 2013 at 11:13 PM, Wayne Werner wa...@waynewerner.com
wrote:
Which you would then use like:
conn = create_conn()
with new_transaction(conn) as tran:
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, but
On Mon, Jul 8, 2013 at 12:23 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
On Mon, 08 Jul 2013 13:11:37 +1000, Chris Angelico wrote:
On Mon, Jul 8, 2013 at 12:23 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
On Mon, Jul 8, 2013 at 3:00 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
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
On 2013-07-04, Dave Angel da...@davea.name wrote:
On 07/04/2013 01:32 AM, Steven D'Aprano wrote:
SNIP
Well, if I ever have more than 63,000,000 variables[1] in a
function, I'll keep that in mind.
SNIP
[1] Based on empirical evidence that Python supports names
with length at
On Fri, Jul 5, 2013 at 11:24 PM, Neil Cerutti ne...@norwich.edu 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
On 2013-07-05, Chris Angelico ros...@gmail.com wrote:
On Fri, Jul 5, 2013 at 11:24 PM, Neil Cerutti
ne...@norwich.edu 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
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 names
On Wed, Jul 3, 2013 at 11:32 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
On 07/04/2013 01:32 AM, Steven D'Aprano wrote:
SNIP
Well, if I ever have more than 63,000,000 variables[1] in a function,
I'll keep that in mind.
SNIP
[1] Based on empirical evidence that Python supports names with length at
least up to one million characters long, and assuming
Dave Angel da...@davea.name 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
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:
On Thu, 04 Jul 2013 03:06:25 -0400, Dave Angel wrote:
On 07/04/2013 01:32 AM, Steven D'Aprano wrote:
SNIP
Well, if I ever have more than 63,000,000 variables[1] in a function,
I'll keep that in mind.
SNIP
[1] Based on empirical evidence that Python supports names with length
On Thu, 04 Jul 2013 15:47:57 +1000, Chris Angelico wrote:
On Thu, Jul 4, 2013 at 3:32 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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.
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:
SNIP
Well, if I ever have more than 63,000,000 variables[1] in a function,
I'll keep that in mind.
SNIP
[1] Based on
On Fri, Jul 5, 2013 at 2:38 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
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:
SNIP
Well, if I ever have more than 63,000,000
On 4 July 2013 17:54, Rotwang sg...@hotmail.co.uk 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 -
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 at
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
On 5 July 2013 03:03, Dave Angel da...@davea.name 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
On 5 July 2013 03:03, Dave Angel da...@davea.name 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,
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
On Thu, Jul 4, 2013 at 1:27 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
On 4 July 2013 05:07, Chris Angelico ros...@gmail.com wrote:
On Thu, Jul 4, 2013 at 1:27 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
With respect to the Huffman coding of declarations, Javascript gets it
backwards. Locals ought to be more common, but they require more
On Thu, Jul 4, 2013 at 2:30 PM, Joshua Landau
joshua.landau...@gmail.com 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):
On 4 July 2013 05:36, Chris Angelico ros...@gmail.com wrote:
On Thu, Jul 4, 2013 at 2:30 PM, Joshua Landau
joshua.landau...@gmail.com 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):
On Thu, 04 Jul 2013 14:07:55 +1000, Chris Angelico wrote:
On Thu, Jul 4, 2013 at 1:27 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
With respect to the Huffman coding of declarations, Javascript gets it
backwards. Locals ought to be more common, but they require more
On Thu, Jul 4, 2013 at 3:32 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
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)
func(i)
60 matches
Mail list logo
