Re: Debugging a difficult refcount issue.
buck writes: > I tried to pinpoint this intermediate allocation with a similar > PyDict_New/LD_PRELOAD interposer, but that isn't working for me[2]. Did you try a gdb watchpoint? -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
On Sat, 17 Dec 2011 23:33:27 -0600, Evan Driscoll wrote: > This would suggest perhaps some keywords might be called for instead of > operators. The barrier to new keywords in Python is very high. Not going to happen for something that already has perfectly good syntax already familiar to Python and Ruby programmers. Might else well try to get C and Java to stop using "..." (ellipses). > In the grand scheme of things the argument packing and > unpacking are not *all* that common, so I don't think the syntactic > burden would be immense. The burden is that you complicate the compiler and reduce the pool of useful names available to the programmer. To be useful, the keywords need to be short, meaningful and memorable -- which means they're already used in code, which you will break needlessly. With operators that otherwise would be illegal, the programmer doesn't need to learn about varargs until they need to. With keywords, the programmer needs to learn "you can't use varargs or kwargs as variable names" practically from day 1. > But then you could also say > def foo(varargs(list) l, kwargs(dict) d) So you're not just adding keywords, you're adding new syntax: something which looks like a function call, but isn't a function call. Another feature which the programmer has to learn just to be able to read Python source code -- and one which almost certainly is going to clash with function annotations as people start using them. I'm going to pose the same question to you I have already posed to Eelco: in your proposal, what happens if the caller has shadowed the list built- in? Does argument l become a built-in list, or does it become whatever type list is currently bound to? Some more questions: Can varargs accepted arbitrary callables, or only a fixed set of known types? How does this differ from what can be done with annotations? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
On Sun, Dec 18, 2011 at 6:31 PM, Steven D'Aprano wrote: > My normal first place to look for something is Wikipedia. Enjoy it before > SOPA kills it. > > http://en.wikipedia.org/wiki/Asterisk#Programming_languages I would never expect to find this sort of thing in the article on the asterisk; maybe I'd look on the language's article, but more likely I would be looking for info on the language's own web site. > On Sat, 17 Dec 2011 23:33:27 -0600, Evan Driscoll wrote: >> In the first pages >> of the four searches matching "python (function)? (star | asterisk)", > > Your search looks overly complicated to me. I understand this to mean that he did four searches: * python star * python function star * python asterisk * python function asterisk > Never underestimate the power of Python's introspection tools, especially > the two simplest ones: print and type. Often you will learn more in 10 > minutes experimentation than in an hour googling. +1 QOTW. I refer to this as "IIDPIO debugging" (Eyed Pio) - If In Doubt, Print It Out. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
On Sat, 17 Dec 2011 21:03:01 -0600, Evan Driscoll wrote: > Something like ML or Haskell, which does not even allow integer to > double promotions, is very strong typing. Something like Java, which > allows some arithmetic conversion and also automatic stringification (a > la "1" + 1) is somewhere in the middle of the spectrum. Personally I'd > put Python even weaker on account of things such as '[1,2]*2' and '1 < > True' being allowed, They are not examples of weak typing. The first is an example of operator overloading, the second is a side-effect of a compromise made for backwards compatibility. If the first example were written: [1, 2].repeat(2) I expect you'd be perfectly happy with it as an unexceptional example of a list method: it takes an integer count, and returns a new list consisting of the elements of the original list repeated twice. If it were written: [1, 2].__mul__(2) you'd probably raise an eyebrow at the ugliness of the method name, but you would be okay with the concept. Well, that's exactly what it is in Python: the list __mul__ method performs sequence multiplication (repeating the contents), which overloads the * operator. No automatic type conversions needed, so not an example of weak typing. As for comparisons between ints and True or False, that's not weak typing either, because True and False *are* ints: bool is a subclass of int. This was done purely for historical reasons: originally Python didn't have a bool type, and you used 0 and 1 by convention for boolean values. When it was decided to add a bool type, the least disruptive way to do this was to define it as a subclass of int. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Make a small function thread safe
Which is why the original .acquire() ... .release() idiom was wrong, this would better express the intent: try: lock.acquire() shared_container.append(...) finally: lock.release() But like everyone mentions, the with statement takes care of all that in a more readable and compact fashion. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug in multiprocessing.reduction?
Yaşar Arabacı wrote: > You can see my all code below, theoritically that code should work I > guess. But I keep getting this error: > [SUBWARNING/MainProcess] thread for sharing handles raised exception : > --- > Traceback (most recent call last): > File "/usr/lib/python2.7/multiprocessing/reduction.py", line 127, in > _serve send_handle(conn, handle_wanted, destination_pid) > File "/usr/lib/python2.7/multiprocessing/reduction.py", line 80, in > send_handle > _multiprocessing.sendfd(conn.fileno(), handle) > OSError: [Errno 9] Bad file descriptor > --- > > Do you see an error in my side, or is this a bug in Python? > Hello, I don't know much about the multiprocessing module, so I won't speculate about bugs ;) however I can tell you that your code works with error on my machine: kev@pluto:~> python mtest.py [DEBUG/MainProcess] created semlock with handle 140252275732480 [DEBUG/MainProcess] created semlock with handle 140252275728384 [DEBUG/MainProcess] created semlock with handle 140252275724288 [DEBUG/MainProcess] Queue._after_fork() [DEBUG/Process-1] Queue._after_fork() [INFO/Process-1] child process calling self.run() [DEBUG/Process-2] Queue._after_fork() [INFO/Process-2] child process calling self.run() [DEBUG/Process-3] Queue._after_fork() [INFO/Process-3] child process calling self.run() [DEBUG/Process-4] Queue._after_fork() [INFO/Process-4] child process calling self.run() [DEBUG/Process-5] Queue._after_fork() [INFO/Process-5] child process calling self.run() [DEBUG/MainProcess] starting listener and thread for sending handles [INFO/MainProcess] created temp directory /tmp/pymp-J3UxCe [DEBUG/MainProcess] Queue._start_thread() [DEBUG/MainProcess] doing self._thread.start() [DEBUG/MainProcess] starting thread to feed data to pipe [DEBUG/MainProcess] ... done self._thread.start() Here "Here" was added to your print line by me. Otherwise I ran your code as is, and sent the string "Hello world" to port 9090 from another console. Hope that helps, Kev -- http://mail.python.org/mailman/listinfo/python-list
Re: calculate difference between two timestamps [newbie]
On 17 dec, 12:20, "Günther Dietrich" wrote:
> nukeymusic wrote:
> >I'm trying to calculate the difference in seconds between two
>
> [...]
>
> >>> import datetime
> >>> date1 = datetime.datetime.strptime("Dec-13-09:47:12", "%b-%d-%H:%M:%S")
> >>> date2 = datetime.datetime.strptime("Dec-13-09:47:39", "%b-%d-%H:%M:%S")
> >>> delta = date2 - date1
> >>> delta_seconds = (delta.days * 60 * 60 * 24) + delta.seconds +
> >>> ((delta.microseconds + 50) / 100)
>
> For very big time differences you should consider to use the Decimal
> arithmetics (standard module Decimal) instead of integer arithmetics
> for the last line.
> If you are sure, that you don't use fractional seconds, you can omit
> the part with 'delta.microseconds'.
>
> Best regards,
>
> Günther
That can very much Günther, this helped me a lot further, I'm only
struggling with one more problem to finish my first python-program.
Could you
tell me why I can't write to the outputfile as I do in the code
below:?
#!/usr/bin/python
#version 16/12/2011
#Example of testfile
#Dec-13-09:46:45 21.4 +4.76442190E-01 8.135530E-06 1.553691E+00
#Dec-13-09:47:12 21.4 +4.76439120E-01 8.135839E-06 1.553726E+00
#Dec-13-09:47:39 21.4 +4.76427260E-01 8.136261E-06 1.553853E+00
import datetime
f = open('testfile','r')
g = open('outputfile','w')
#get line 1 from input file:
line1=f.readline()
#get first element in line 1:
date1=line1.rsplit()[0]
#convert first element tot structured date time
struct_date1=datetime.datetime.strptime(date1, "%b-%d-%H:%M:%S")
for line in f:
temp=line.rsplit()
delta=datetime.datetime.strptime(temp[0], "%b-%d-%H:%M:%S")-
datetime.datetime.strptime(date1, "%b-%d-%H:%M:%S")
delta_seconds = (delta.days * 60 * 60 * 24) + delta.seconds +
((delta.microseconds + 50) / 100)
temp[0]=delta_seconds
#the following line is wrong, but I don't know how to fix it:
g.write(temp)
#Close files
f.close()
g.close()
thanks in advance
nukey
--
http://mail.python.org/mailman/listinfo/python-list
Module msvcrt for Python
I am running Python 2.6.6 on a Windows Vista platform and for some reason the module msvcrt is not present. How can I install the msvcrt module in my Python 2.6.6? God Jul :-) -- http://mail.python.org/mailman/listinfo/python-list
how to run python-script from the python promt? [absolute newbie]
How can I load a python-script after starting python in the interactive mode? I tried with >>>load 'myscript.py' >>>myscript.py >>>myscript but none of these works, so the only way I could work further until now was copy/paste line per line of my python-script to the interactive mode prompt I do know how to run the script non-interactively, but what I want to do is adding lines to the code I have written thus far in interactive mode. thanks in advance nukey -- http://mail.python.org/mailman/listinfo/python-list
Re: how to run python-script from the python promt? [absolute newbie]
On Sun, Dec 18, 2011 at 10:00 PM, nukeymusic wrote: > How can I load a python-script after starting python in the > interactive mode? > I tried with load 'myscript.py' myscript.py myscript > > but none of these works, so the only way I could work further until > now was copy/paste line per line of my python-script to the > interactive mode prompt The easiest way to load a file is to import it. However, this is not quite identical to loading the script into the current session. If your script mainly defines functions, you can either: import myscript or from myscript import * and it'll do more or less what you expect; however, it will execute in its own module context, so globals from your current session won't be available to it. Tip for pasting: Indent every line of your code at least one space/tab, prefix it with "if True:", and then you can paste it all at once. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: calculate difference between two timestamps [newbie]
nukeymusic wrote:
> On 17 dec, 12:20, "Günther Dietrich" wrote:
>> nukeymusic wrote:
>> >I'm trying to calculate the difference in seconds between two
>>
>> [...]
>>
>> >>> import datetime
>> >>> date1 = datetime.datetime.strptime("Dec-13-09:47:12",
>> >>> "%b-%d-%H:%M:%S") date2 =
>> >>> datetime.datetime.strptime("Dec-13-09:47:39", "%b-%d-%H:%M:%S") delta
>> >>> = date2 - date1 delta_seconds = (delta.days * 60 * 60 * 24) +
>> >>> delta.seconds + ((delta.microseconds + 50) / 100)
>>
>> For very big time differences you should consider to use the Decimal
>> arithmetics (standard module Decimal) instead of integer arithmetics
>> for the last line.
>> If you are sure, that you don't use fractional seconds, you can omit
>> the part with 'delta.microseconds'.
>>
>> Best regards,
>>
>> Günther
> That can very much Günther, this helped me a lot further, I'm only
> struggling with one more problem to finish my first python-program.
> Could you
> tell me why I can't write to the outputfile as I do in the code
> below:?
> #!/usr/bin/python
> #version 16/12/2011
> #Example of testfile
> #Dec-13-09:46:45 21.4 +4.76442190E-01 8.135530E-06 1.553691E+00
> #Dec-13-09:47:12 21.4 +4.76439120E-01 8.135839E-06 1.553726E+00
> #Dec-13-09:47:39 21.4 +4.76427260E-01 8.136261E-06 1.553853E+00
> import datetime
> f = open('testfile','r')
> g = open('outputfile','w')
> #get line 1 from input file:
> line1=f.readline()
> #get first element in line 1:
> date1=line1.rsplit()[0]
> #convert first element tot structured date time
> struct_date1=datetime.datetime.strptime(date1, "%b-%d-%H:%M:%S")
> for line in f:
> temp=line.rsplit()
> delta=datetime.datetime.strptime(temp[0], "%b-%d-%H:%M:%S")-
> datetime.datetime.strptime(date1, "%b-%d-%H:%M:%S")
> delta_seconds = (delta.days * 60 * 60 * 24) + delta.seconds +
> ((delta.microseconds + 50) / 100)
> temp[0]=delta_seconds
> #the following line is wrong, but I don't know how to fix it:
> g.write(temp)
> #Close files
> f.close()
> g.close()
The write() method only accepts strings; you have to convert the temp list
to a string before passing it on. The minimal change:
for line in f:
temp = line.rsplit()
delta = (datetime.datetime.strptime(temp[0], "%b-%d-%H:%M:%S")
-datetime.datetime.strptime(date1, "%b-%d-%H:%M:%S"))
delta_seconds = ((delta.days * 60 * 60 * 24) + delta.seconds
+ ((delta.microseconds + 50) / 100))
temp[0] = str(delta_seconds)
g.write(" ".join(temp) + "\n")
Other observations:
- you are repeating calculations in the loop that you can do (and did)
outside.
- use four-space indent for better readability
- there's no need to use rsplit(); use split()
After a few other modifications:
import datetime
def parse_line(line):
date, rest = line.split(None, 1)
date = datetime.datetime.strptime(date, "%b-%d-%H:%M:%S")
return date, rest
with open('testfile','r') as f:
with open('outputfile','w') as g:
first_date, first_rest = parse_line(next(f))
for line in f:
cur_date, rest = parse_line(line)
delta = cur_date - first_date
delta_seconds = ((delta.days * 60 * 60 * 24) + delta.seconds
+ ((delta.microseconds + 50) / 100))
g.write("%s %s" % (delta_seconds, rest))
--
http://mail.python.org/mailman/listinfo/python-list
Re: how to run python-script from the python promt? [absolute newbie]
nukeymusic wrote:
> How can I load a python-script after starting python in the
> interactive mode?
> I tried with
load 'myscript.py'
myscript.py
myscript
>
> but none of these works, so the only way I could work further until
> now was copy/paste line per line of my python-script to the
> interactive mode prompt
> I do know how to run the script non-interactively, but what I want to
> do is adding lines to the code I have written thus far in interactive
> mode.
>
> thanks in advance
> nukey
Hello,
You can make the code in your script available to the interpreter by typing
import myscript
(assuming that you are running the interpreter in the same directory that
contains myscript.py)
You can access functions, classes and other top-level objects in your script
by prefixing their names with "myscript" and a dot (".") e.g.
myscript.myfunc, myscript.MyClass, myscript.myvar
You can't really edit your script in the interpreter, but you can edit and
save in a text editor and then type
reload(myscript)
in the interpreter to refresh its version of the myscript code.
N.B. when you import/reload your script the interpreter will immediately
execute any code that is not enclosed in a function or class definition.
Cheers,
Kev
--
http://mail.python.org/mailman/listinfo/python-list
Re: Module msvcrt for Python
On 18-Dec-2011 11:31, Virgil Stokes wrote: I am running Python 2.6.6 on a Windows Vista platform and for some reason the module msvcrt is not present. How can I install the msvcrt module in my Python 2.6.6? God Jul :-) I found the problem! My code was using Python 2.5 (inside cygwin) by default and there it was unable to import msvcrt. But, when I ran the same code in my Python 2.6 installation it worked as it should (msvcrt module was imported). Sorry for the "noise". Best :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: how to run python-script from the python promt? [absolute newbie]
On 12/18/2011 10:00 PM, nukeymusic wrote: How can I load a python-script after starting python in the interactive mode? I tried with load 'myscript.py' myscript.py myscript but none of these works, so the only way I could work further until now was copy/paste line per line of my python-script to the interactive mode prompt I do know how to run the script non-interactively, but what I want to do is adding lines to the code I have written thus far in interactive mode. thanks in advance nukey The normal python shell doesn't directly support doing that, although there are several workaround with (ab)using the 'import' statement, it had several subtleties with how module are cached. Try the ipython shell; in ipython you can load a file into the current interpreter session using the %run magic command. -- http://mail.python.org/mailman/listinfo/python-list
Re: calculate difference between two timestamps [newbie]
On 12/18/2011 10:43 PM, Peter Otten wrote:
nukeymusic wrote:
On 17 dec, 12:20, "Günther Dietrich" wrote:
nukeymusic wrote:
I'm trying to calculate the difference in seconds between two
[...]
import datetime
date1 = datetime.datetime.strptime("Dec-13-09:47:12",
"%b-%d-%H:%M:%S") date2 =
datetime.datetime.strptime("Dec-13-09:47:39", "%b-%d-%H:%M:%S") delta
= date2 - date1 delta_seconds = (delta.days * 60 * 60 * 24) +
delta.seconds + ((delta.microseconds + 50) / 100)
For very big time differences you should consider to use the Decimal
arithmetics (standard module Decimal) instead of integer arithmetics
for the last line.
If you are sure, that you don't use fractional seconds, you can omit
the part with 'delta.microseconds'.
Best regards,
Günther
That can very much Günther, this helped me a lot further, I'm only
struggling with one more problem to finish my first python-program.
Could you
tell me why I can't write to the outputfile as I do in the code
below:?
#!/usr/bin/python
#version 16/12/2011
#Example of testfile
#Dec-13-09:46:45 21.4 +4.76442190E-01 8.135530E-06 1.553691E+00
#Dec-13-09:47:12 21.4 +4.76439120E-01 8.135839E-06 1.553726E+00
#Dec-13-09:47:39 21.4 +4.76427260E-01 8.136261E-06 1.553853E+00
import datetime
f = open('testfile','r')
g = open('outputfile','w')
#get line 1 from input file:
line1=f.readline()
#get first element in line 1:
date1=line1.rsplit()[0]
#convert first element tot structured date time
struct_date1=datetime.datetime.strptime(date1, "%b-%d-%H:%M:%S")
for line in f:
temp=line.rsplit()
delta=datetime.datetime.strptime(temp[0], "%b-%d-%H:%M:%S")-
datetime.datetime.strptime(date1, "%b-%d-%H:%M:%S")
delta_seconds = (delta.days * 60 * 60 * 24) + delta.seconds +
((delta.microseconds + 50) / 100)
temp[0]=delta_seconds
#the following line is wrong, but I don't know how to fix it:
g.write(temp)
#Close files
f.close()
g.close()
The write() method only accepts strings; you have to convert the temp list
to a string before passing it on. The minimal change:
for line in f:
temp = line.rsplit()
delta = (datetime.datetime.strptime(temp[0], "%b-%d-%H:%M:%S")
-datetime.datetime.strptime(date1, "%b-%d-%H:%M:%S"))
delta_seconds = ((delta.days * 60 * 60 * 24) + delta.seconds
+ ((delta.microseconds + 50) / 100))
temp[0] = str(delta_seconds)
g.write(" ".join(temp) + "\n")
Other observations:
- you are repeating calculations in the loop that you can do (and did)
outside.
- use four-space indent for better readability
- there's no need to use rsplit(); use split()
After a few other modifications:
import datetime
def parse_line(line):
date, rest = line.split(None, 1)
date = datetime.datetime.strptime(date, "%b-%d-%H:%M:%S")
return date, rest
with open('testfile','r') as f:
with open('outputfile','w') as g:
first_date, first_rest = parse_line(next(f))
for line in f:
cur_date, rest = parse_line(line)
delta = cur_date - first_date
delta_seconds = ((delta.days * 60 * 60 * 24) + delta.seconds
+ ((delta.microseconds + 50) / 100))
g.write("%s %s" % (delta_seconds, rest))
minor improvement, you can do:
with open('testfile','r') as f, open('outputfile','w') as g:
...
instead of the nested with-block.
Also, you can use `delta.total_seconds()` instead of `delta_seconds =
((delta.days * 60 * 60 * 24) + delta.seconds + ((delta.microseconds +
50) / 100))`
Therefore (untested):
import datetime
def parse_line(line):
date, rest = line.split(None, 1)
date = datetime.datetime.strptime(date, "%b-%d-%H:%M:%S")
return date, rest
with open('testfile','r') as f, open('outputfile','w') as g:
first_date, first_rest = parse_line(next(f))
for line in f:
cur_date, rest = parse_line(line)
delta = cur_date - first_date
g.write("%s %s" % (int(round(delta.total_seconds())), rest))
--
http://mail.python.org/mailman/listinfo/python-list
Re: how to run python-script from the python promt? [absolute newbie]
On 18 dec, 13:39, Lie Ryan wrote: > On 12/18/2011 10:00 PM, nukeymusic wrote: > > > > > > > > > > > How can I load a python-script after starting python in the > > interactive mode? > > I tried with > load 'myscript.py' > myscript.py > myscript > > > but none of these works, so the only way I could work further until > > now was copy/paste line per line of my python-script to the > > interactive mode prompt > > I do know how to run the script non-interactively, but what I want to > > do is adding lines to the code I have written thus far in interactive > > mode. > > > thanks in advance > > nukey > > The normal python shell doesn't directly support doing that, although > there are several workaround with (ab)using the 'import' statement, it > had several subtleties with how module are cached. Try the ipython > shell; in ipython you can load a file into the current interpreter > session using the %run magic command. I guess you mean the following command? %run 'myscript.py' is this correct? thanks nukey -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
In article , Chris Angelico wrote: > > Never underestimate the power of Python's introspection tools, especially > > the two simplest ones: print and type. Often you will learn more in 10 > > minutes experimentation than in an hour googling. > > +1 QOTW. I refer to this as "IIDPIO debugging" (Eyed Pio) - If In > Doubt, Print It Out. I always knew it by the name "Ask the computer". As in, "WTF is foo? Let's ask the computer!". In addition to print and type, I'm a big fan of dir(). Often, I know an object has a method to do what I want, but I can't remember the name. For example, the other day, I was using a set (which I don't use very often). I needed the method to remove an item from the set. Faster than finding the right place in the docs, I just fired up an interpreter and typed dir(set()) at it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
On Mon, Dec 19, 2011 at 12:58 AM, Roy Smith wrote: > In addition to print and type, I'm a big fan of dir(). Often, I know an > object has a method to do what I want, but I can't remember the name. > For example, the other day, I was using a set (which I don't use very > often). I needed the method to remove an item from the set. Faster > than finding the right place in the docs, I just fired up an interpreter > and typed dir(set()) at it. That's excellent when all you need is the name. I usually have IDLE running (all the time - which sometimes produces oddities after I experiment with monkey-patching some module or other, and then oddly enough, things don't work properly!!), and will snap off "help(foo)" for any foo. Unfortunately help() is at times unhelpful, and even at its best it's very spammy. There's no one best solution; the successful programmer will usually have a large toolset at his disposal. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
On Dec 18, 1:59 am, Steven D'Aprano wrote: > On Sat, 17 Dec 2011 06:38:22 -0800, Eelco wrote: > > Type constraints: > > > In case the asterisk is not used to signal unpacking, but rather to > > signal packing, its semantics is essentially that of a type constraint. > > "Type constraint" normally refers to type restrictions on *input*: it is > a restriction on what types are accepted. When it refers to output, it is > not normally a restriction, therefore "constraint" is inappropriate. > Instead it is normally described as a coercion, cast or conversion. > Automatic type conversions are the opposite of a constraint: it is a > loosening of restrictions. "I don't have to use a list, I can use any > sequence or iterator". Casts or conversions are a runtime concept; im talking about declarations. That seems to be the source of your confusion. > In iterator unpacking, it is the *output* which is a list, not a > restriction on input: in the statement: > > head, *tail = sequence > > tail may not exist before the assignment, and so describing this as a > constraint on the type of tail is completely inappropriate. Yes, the variable tail is being (re)declared here. Thats exactly why I call it a type constraint. Im not sure what the CS books have to say on the matter, I guess this use of the term entered my lexicon through the C# developer team. Either way, you seem to be the only one who does not grok my intended meaning, so I suggest you try reading it again. > > The statement: > > > head, tail = sequence > > > Signifies regular unpacking. However, if we add an asterisk, as in: > > > head, *tail = sequence > > > We demand that tail not be just any python object, but rather a list. > > We don't demand anything, any more than when we say: > > for x in range(1, 100): > > we "demand" that x is not just any python object, but rather an int. > > Rather, we accept what we're given: in case of range and the for loop, we > are given an int. In the case of extended tuple unpacking, we are given a > list. for x in range is syntactic sugar for a series of assignments to x; x is an unconstrained variable that will indeed take anything it gets; the semantics of what comes after 'x' does in no way depend on x itself. head, tail = l and head, *tail = l mean something completely different, and the only difference is a constraint placed on tail, which forces the semantics to be different; the righthand side, or what is to be assigned, is identical. Of course one can just regard it as syntactic sugar for head, tail = unpackheadandtailaslist(l); but the syntactic sugar achieves that same end through a type constraint on tail. Really. > You are jumping to conclusions about implementation details which aren't > supported by the visible behaviour. What evidence do you have that > iterator unpacking creates a tuple first and then converts it to a list? You are jumping to conclusions about my opinion which aren't supported by my visible behaviour. What evidence do you have that I ever even said any such thing? > > The aim of this PEP, is that this type-constraint syntax is expanded > > upon. We should be careful here to distinguish with providing optional > > type constraints throughout python as a whole; this is not our aim. > > Iterator unpacking is no more about type constraints than is len(). Because you wish to keep nitpicking about my usage of the term 'type constraint' (even though you have not introduced an alternative term yourself), or because you actually disagree with the content of my message? -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
On Dec 18, 5:52 am, buck wrote:
> I like the spirit of this. Let's look at your examples.
Glad to see an actual on-topic reply; thanks.
> > Examples of use:
> > head, tail::tuple = ::sequence
> > def foo(args::list, kwargs::dict): pass
> > foo(::args, ::kwargs)
>
> My initial reaction was "nonono!", but this is simply because of the
> ugliness. The double-colon is very visually busy.
I would have preferred the single colon, but its taken. But exactly
this syntax is used in other languages (for what that is worth...)
> I find that your second example is inconsistent with the others. If we say
> that the variable-name is always on the right-hand-side, we get:
>
> > def foo(list::args, dict::kwargs): pass
>
> This nicely mirrors other languages (such as in your C# example: "float
> foo") as well as the old python behavior (prefixing variables with */** to
> modify the assignment).
The link in my OP has the BDFL discussing type constraints; he also
prefers identifier:type. Many modern languages have something similar.
How is my second example inconsistent?
> As for the separator, let's examine the available ascii punctuation.
> Excluding valid variable characters, whitespace, and operators, we have:
>
> ! -- ok.
> " -- can't use this. Would look like a string.
> # -- no. Would looks like a comment.
> $ -- ok.
> ' -- no. Would look like a string.
> ( -- no. Would look like a function.
> ) -- no. Would look like ... bad syntax.
> , -- no. Would indicate a separate item in the variable list.
> . -- no. Would look like an attribute.
> : -- ok, maybe. Seems confusing in a colon-terminated statement.
> ; -- no, just no.
> ? -- ok.
> @ -- ok.
> [ -- no. Would look like indexing.
> ] -- no.
> ` -- no. Would look like a string?
> { -- too strange} -- too strange
>
> ~ -- ok.
>
> That leaves these. Which one looks least strange?
>
> float ! x = 1
> float $ x = 1
> float ? x = 1
> float @ x = 1
>
> The last one looks decorator-ish, but maybe that's proper. The implementation
> of this would be quite decorator-like: take the "normal" value of x, pass it
> through the indicated function, assign that value back to x.
I dont think thats too proper an analogy. The type constraint does not
just coerce the content that is bound to the variable, it influences
the semantics of the whole statement; so insofar there is a suggested
relation with decorators, id rather not have it.
>
> Try these on for size.
>
> head, @tuple tail = sequence
> def foo(@list args, @dict kwargs): pass
> foo(@args, @kwargs)
>
> For backward compatibility, we could say that the unary * is identical to
> @list and unary ** is identical to @dict.
Yes, maximum backwards compatibility would be great.
--
http://mail.python.org/mailman/listinfo/python-list
Re: calculate difference between two timestamps [newbie]
On 18 dec, 13:58, Lie Ryan wrote:
> On 12/18/2011 10:43 PM, Peter Otten wrote:
>
>
>
>
>
>
>
>
>
> > nukeymusic wrote:
>
> >> On 17 dec, 12:20, "Günther Dietrich" wrote:
> >>> nukeymusic wrote:
> I'm trying to calculate the difference in seconds between two
>
> >>> [...]
>
> >> import datetime
> >> date1 = datetime.datetime.strptime("Dec-13-09:47:12",
> >> "%b-%d-%H:%M:%S") date2 =
> >> datetime.datetime.strptime("Dec-13-09:47:39", "%b-%d-%H:%M:%S") delta
> >> = date2 - date1 delta_seconds = (delta.days * 60 * 60 * 24) +
> >> delta.seconds + ((delta.microseconds + 50) / 100)
>
> >>> For very big time differences you should consider to use the Decimal
> >>> arithmetics (standard module Decimal) instead of integer arithmetics
> >>> for the last line.
> >>> If you are sure, that you don't use fractional seconds, you can omit
> >>> the part with 'delta.microseconds'.
>
> >>> Best regards,
>
> >>> Günther
> >> That can very much Günther, this helped me a lot further, I'm only
> >> struggling with one more problem to finish my first python-program.
> >> Could you
> >> tell me why I can't write to the outputfile as I do in the code
> >> below:?
> >> #!/usr/bin/python
> >> #version 16/12/2011
> >> #Example of testfile
> >> #Dec-13-09:46:45 21.4 +4.76442190E-01 8.135530E-06 1.553691E+00
> >> #Dec-13-09:47:12 21.4 +4.76439120E-01 8.135839E-06 1.553726E+00
> >> #Dec-13-09:47:39 21.4 +4.76427260E-01 8.136261E-06 1.553853E+00
> >> import datetime
> >> f = open('testfile','r')
> >> g = open('outputfile','w')
> >> #get line 1 from input file:
> >> line1=f.readline()
> >> #get first element in line 1:
> >> date1=line1.rsplit()[0]
> >> #convert first element tot structured date time
> >> struct_date1=datetime.datetime.strptime(date1, "%b-%d-%H:%M:%S")
> >> for line in f:
> >> temp=line.rsplit()
> >> delta=datetime.datetime.strptime(temp[0], "%b-%d-%H:%M:%S")-
> >> datetime.datetime.strptime(date1, "%b-%d-%H:%M:%S")
> >> delta_seconds = (delta.days * 60 * 60 * 24) + delta.seconds +
> >> ((delta.microseconds + 50) / 100)
> >> temp[0]=delta_seconds
> >> #the following line is wrong, but I don't know how to fix it:
> >> g.write(temp)
> >> #Close files
> >> f.close()
> >> g.close()
>
> > The write() method only accepts strings; you have to convert the temp list
> > to a string before passing it on. The minimal change:
>
> > for line in f:
> > temp = line.rsplit()
> > delta = (datetime.datetime.strptime(temp[0], "%b-%d-%H:%M:%S")
> > -datetime.datetime.strptime(date1, "%b-%d-%H:%M:%S"))
> > delta_seconds = ((delta.days * 60 * 60 * 24) + delta.seconds
> > + ((delta.microseconds + 50) / 100))
> > temp[0] = str(delta_seconds)
> > g.write(" ".join(temp) + "\n")
>
> > Other observations:
>
> > - you are repeating calculations in the loop that you can do (and did)
> > outside.
>
> > - use four-space indent for better readability
>
> > - there's no need to use rsplit(); use split()
>
> > After a few other modifications:
>
> > import datetime
>
> > def parse_line(line):
> > date, rest = line.split(None, 1)
> > date = datetime.datetime.strptime(date, "%b-%d-%H:%M:%S")
> > return date, rest
>
> > with open('testfile','r') as f:
> > with open('outputfile','w') as g:
> > first_date, first_rest = parse_line(next(f))
> > for line in f:
> > cur_date, rest = parse_line(line)
> > delta = cur_date - first_date
> > delta_seconds = ((delta.days * 60 * 60 * 24) + delta.seconds
> > + ((delta.microseconds + 50) / 100))
> > g.write("%s %s" % (delta_seconds, rest))
>
> minor improvement, you can do:
>
> with open('testfile','r') as f, open('outputfile','w') as g:
> ...
>
> instead of the nested with-block.
>
> Also, you can use `delta.total_seconds()` instead of `delta_seconds =
> ((delta.days * 60 * 60 * 24) + delta.seconds + ((delta.microseconds +
> 50) / 100))`
>
> Therefore (untested):
>
> import datetime
>
> def parse_line(line):
> date, rest = line.split(None, 1)
> date = datetime.datetime.strptime(date, "%b-%d-%H:%M:%S")
> return date, rest
>
> with open('testfile','r') as f, open('outputfile','w') as g:
> first_date, first_rest = parse_line(next(f))
> for line in f:
> cur_date, rest = parse_line(line)
> delta = cur_date - first_date
> g.write("%s %s" % (int(round(delta.total_seconds())), rest))
thanks and also thanks to all the others who were so kind to help me
out with my first python-script.
I tested your alternatives and they work, the only a minor
inconvenience is that the first line of the inputfile gets lost i.e.
the first timestamp should become zero (seconds)
best regards,
nukey
--
http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
On Dec 18, 6:33 am, Evan Driscoll wrote: > On 12/17/2011 22:52, buck wrote:> Try these on for size. > > > head, @tuple tail = sequence > > def foo(@list args, @dict kwargs): pass > > foo(@args, @kwargs) > > > For backward compatibility, we could say that the unary * is identical to > > @list and unary ** is identical to @dict. > > I like this idea much more than the original one. In addition to the > arguments buck puts forth, which I find compelling, I have one more: you > go to great length to say "this isn't really type checking in any sense" > (which is true)... but then you go forth and pick a syntax that looks > almost exactly like how you name types in many languages! (In fact, > except for the fact that it's inline, the 'object :: type' syntax is > *exactly* how you name types in Haskell.) No, its not type *checking*, its type *declaration*. I tried to go to great lengths to point that out, but it appears I did not do a very good job :). Type declaration is exactly what I want, and insofar this syntax has already found adoptation elsewhere, ill consider that a plus. > I have a bigger objection with the general idea, however.It seems very > strange that you should have to specify types to use it. If the */** > syntax were removed, that would make the proposed syntax very very > unusual for Python. I could be missing something, but I can think of any > other place where you have to name a type except where the type is an > integral part of what you're trying to do. (I would not say that > choosing between tuples and lists are an integral part of dealing with > vararg functions.) If */** were to stick around, I could see 99% of > users continuing to use them. And then what has the new syntax achieved? Good point; technically the askeriskes could be kept for backwards compatibility, but that would break 'there should only be one way to do it'. Indeed it would be unusual for python to have to explicitly name a type, but implicitly ** does very much the same. Its just a cryptic way of saying 'dict please'. > You can fix this if you don't require the types and just allow the user > to say "def foo(@args)" and "foo(@args)". Except... that's starting to > look pretty familiar... (Not to mention if you just omit the type from > the examples above you need another way to distinguish between args and > kwargs.) Yes, one could opt for a syntax where the collection type is optional and a sensible default is chosen, But to me that would largely defeat the point; I very much like the added verbosity and explicitness. args- tuple and kwargs-dict; that just has a much better ring to it than star-star-kwargs, or whatever other cryptic symbol you use. > I have one more suggestion. > > I do have one more thing to point out, which is that currently the > Python vararg syntax is very difficult to Google for. In the first pages > of the four searches matching "python (function)? (star | asterisk)", > there was just one relevant hit on python.org which wasn't a bug report. > I certainly remember having a small amount of difficulty figuring out > what the heck * and ** did the first time I encountered them. > > This would suggest perhaps some keywords might be called for instead of > operators. In the grand scheme of things the argument packing and > unpacking are not *all* that common, so I don't think the syntactic > burden would be immense. The bigger issue, of course, would be picking > good words. > > This also helps with the issue above. Let's say we'll use 'varargs' and > 'kwargs', though the latter too well-ingrained in code to steal. (I > don't want to get too much into the debate over *what* word to choose. > Also these don't match the 'head, *tail = l' syntax very well.) Then we > could say: > def foo(varargs l, kwargs d): > bar(varargs l, kwargs d) > and varargs would be equivalent to * and kwargs would be equivalent to > **. But then you could also say > def foo(varargs(list) l, kwargs(dict) d) I agree; I had the same experience. But according to others our opinion is wrong, and we should just become better at using google. -- http://mail.python.org/mailman/listinfo/python-list
Re: calculate difference between two timestamps [newbie]
nukeymusic wrote:
> thanks and also thanks to all the others who were so kind to help me
> out with my first python-script.
> I tested your alternatives and they work, the only a minor
> inconvenience is that the first line of the inputfile gets lost i.e.
> the first timestamp should become zero (seconds)
That should be easy to fix:
>> with open('testfile','r') as f, open('outputfile','w') as g:
>> first_date, first_rest = parse_line(next(f))
g.write("0 %s" % first_rest)
>> for line in f:
>> cur_date, rest = parse_line(line)
>> delta = cur_date - first_date
>> g.write("%s %s" % (int(round(delta.total_seconds())), rest))
--
http://mail.python.org/mailman/listinfo/python-list
Re: calculate difference between two timestamps [newbie]
On 18 dec, 16:01, Peter Otten <__pete...@web.de> wrote:
> nukeymusic wrote:
> > thanks and also thanks to all the others who were so kind to help me
> > out with my first python-script.
> > I tested your alternatives and they work, the only a minor
> > inconvenience is that the first line of the inputfile gets lost i.e.
> > the first timestamp should become zero (seconds)
>
> That should be easy to fix:
>
> >> with open('testfile','r') as f, open('outputfile','w') as g:
> >> first_date, first_rest = parse_line(next(f))
>
> g.write("0 %s" % first_rest)
>
>
>
>
>
>
>
> >> for line in f:
> >> cur_date, rest = parse_line(line)
> >> delta = cur_date - first_date
> >> g.write("%s %s" % (int(round(delta.total_seconds())), rest))
thanks, that solves it, you're too kind
nukey
--
http://mail.python.org/mailman/listinfo/python-list
Re: calculate difference between two timestamps [newbie]
On 18 dec, 13:58, Lie Ryan wrote:
> On 12/18/2011 10:43 PM, Peter Otten wrote:
>
>
>
>
>
>
>
>
>
> > nukeymusic wrote:
>
> >> On 17 dec, 12:20, "Günther Dietrich" wrote:
> >>> nukeymusic wrote:
> I'm trying to calculate the difference in seconds between two
>
> >>> [...]
>
> >> import datetime
> >> date1 = datetime.datetime.strptime("Dec-13-09:47:12",
> >> "%b-%d-%H:%M:%S") date2 =
> >> datetime.datetime.strptime("Dec-13-09:47:39", "%b-%d-%H:%M:%S") delta
> >> = date2 - date1 delta_seconds = (delta.days * 60 * 60 * 24) +
> >> delta.seconds + ((delta.microseconds + 50) / 100)
>
> >>> For very big time differences you should consider to use the Decimal
> >>> arithmetics (standard module Decimal) instead of integer arithmetics
> >>> for the last line.
> >>> If you are sure, that you don't use fractional seconds, you can omit
> >>> the part with 'delta.microseconds'.
>
> >>> Best regards,
>
> >>> Günther
> >> That can very much Günther, this helped me a lot further, I'm only
> >> struggling with one more problem to finish my first python-program.
> >> Could you
> >> tell me why I can't write to the outputfile as I do in the code
> >> below:?
> >> #!/usr/bin/python
> >> #version 16/12/2011
> >> #Example of testfile
> >> #Dec-13-09:46:45 21.4 +4.76442190E-01 8.135530E-06 1.553691E+00
> >> #Dec-13-09:47:12 21.4 +4.76439120E-01 8.135839E-06 1.553726E+00
> >> #Dec-13-09:47:39 21.4 +4.76427260E-01 8.136261E-06 1.553853E+00
> >> import datetime
> >> f = open('testfile','r')
> >> g = open('outputfile','w')
> >> #get line 1 from input file:
> >> line1=f.readline()
> >> #get first element in line 1:
> >> date1=line1.rsplit()[0]
> >> #convert first element tot structured date time
> >> struct_date1=datetime.datetime.strptime(date1, "%b-%d-%H:%M:%S")
> >> for line in f:
> >> temp=line.rsplit()
> >> delta=datetime.datetime.strptime(temp[0], "%b-%d-%H:%M:%S")-
> >> datetime.datetime.strptime(date1, "%b-%d-%H:%M:%S")
> >> delta_seconds = (delta.days * 60 * 60 * 24) + delta.seconds +
> >> ((delta.microseconds + 50) / 100)
> >> temp[0]=delta_seconds
> >> #the following line is wrong, but I don't know how to fix it:
> >> g.write(temp)
> >> #Close files
> >> f.close()
> >> g.close()
>
> > The write() method only accepts strings; you have to convert the temp list
> > to a string before passing it on. The minimal change:
>
> > for line in f:
> > temp = line.rsplit()
> > delta = (datetime.datetime.strptime(temp[0], "%b-%d-%H:%M:%S")
> > -datetime.datetime.strptime(date1, "%b-%d-%H:%M:%S"))
> > delta_seconds = ((delta.days * 60 * 60 * 24) + delta.seconds
> > + ((delta.microseconds + 50) / 100))
> > temp[0] = str(delta_seconds)
> > g.write(" ".join(temp) + "\n")
>
> > Other observations:
>
> > - you are repeating calculations in the loop that you can do (and did)
> > outside.
>
> > - use four-space indent for better readability
>
> > - there's no need to use rsplit(); use split()
>
> > After a few other modifications:
>
> > import datetime
>
> > def parse_line(line):
> > date, rest = line.split(None, 1)
> > date = datetime.datetime.strptime(date, "%b-%d-%H:%M:%S")
> > return date, rest
>
> > with open('testfile','r') as f:
> > with open('outputfile','w') as g:
> > first_date, first_rest = parse_line(next(f))
> > for line in f:
> > cur_date, rest = parse_line(line)
> > delta = cur_date - first_date
> > delta_seconds = ((delta.days * 60 * 60 * 24) + delta.seconds
> > + ((delta.microseconds + 50) / 100))
> > g.write("%s %s" % (delta_seconds, rest))
>
> minor improvement, you can do:
>
> with open('testfile','r') as f, open('outputfile','w') as g:
> ...
>
> instead of the nested with-block.
>
> Also, you can use `delta.total_seconds()` instead of `delta_seconds =
> ((delta.days * 60 * 60 * 24) + delta.seconds + ((delta.microseconds +
> 50) / 100))`
>
> Therefore (untested):
>
> import datetime
>
> def parse_line(line):
> date, rest = line.split(None, 1)
> date = datetime.datetime.strptime(date, "%b-%d-%H:%M:%S")
> return date, rest
>
> with open('testfile','r') as f, open('outputfile','w') as g:
> first_date, first_rest = parse_line(next(f))
> for line in f:
> cur_date, rest = parse_line(line)
> delta = cur_date - first_date
> g.write("%s %s" % (int(round(delta.total_seconds())), rest))
thanks to you and all the others for helping me out with my first
python-script. I tested your alternatives and they do work.
The only minor inconvenience with the scripts is that the output-file
misses the first line i.e. the first timestamp should be reset to zero
(seconds),
but as these log-files are very large, missing one measurement is not
too bad
best regards
nukey
--
http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
I'm just going to throw myself in the conversation obtusely.I felt we
needed some real code. These are literally the first two samples I had on
hand.
!!! OUT OF CONTEXT REAL CODE ALERT !!!
###
formatter = formatter.format(**color).replace("(","{").replace(")","}")
print("\n\n".join(formatter.format(**d) for d in db))
# vs #
formatter = formatter.format(::(),
::color).replace("(","{").replace(")","}")
print("\n\n".join(formatter.format(::(), ::d) for d in db))
# What do we do for "format(**kwargs)"?
# With the current guess of mine, I'm thinking "what does ::() do?" and
"why are there two double-colons?".
# Aside from that it looks not much different/worse.
# and #
def checkLoad(self, *args, **kwargs):
if getattr(self, x) == None: getattr(self, loadx)()
if fakeself:
return function(getattr(self, x), *args, **kwargs)
else:
return function(self, *args, **kwargs)
return checkLoad
# vs #
def checkLoad(self, tuple::args, dict::kwargs):
if getattr(self, x) == None: getattr(self, loadx)()
if fakeself:
return function(getattr(self, x), ::args, ::kwargs)
else:
return function(self, ::args, ::kwargs)
return checkLoad
# It looks much the same, but how does it benefit me?
# "*args" is very distinct from "**kwargs" in my opinion. "tuple"/"dict"
doesn't have that.
# That said, the second works better with my syntax highlighter (although
pylint then swears at me).
#
Before I actually put the syntax in context I hated this. Now I just really
dislike it.
There is one big thing bugging me: How do I do: "foo(**kwargs)"? My
solution was to use "foo(::(), ::kwargs)", but it's obviously not a great
alternative.
There is another, smaller one. Wrapper functions often just want to pass
values straight through them. They don't care that it's a tuple. They don't
care that it's a dict. They're just going to throw it across. Without "def
foo(::args)" syntax, that's just a waste of a lookup. With "def
foo(::args)" syntax you lose the discrimination of args and kwargs,
resulting in the same problem above. Finally, it's uglier when without.
I do have one suggestion:
foo(*args, **kwargs): pass
foo(tuple(*) args, dict(**) kwargs): pass
foo(dict(**) kwargs): pass
foo(*, bar="spam"): pass
# this is illegal because unbound "catchalls" don't catch anything, as they
do today
foo(tuple(*), bar="spam"): pass
I'll leave you to guess how it works. If you can't it's obviously not
obvious enough.
Advantages:
"*" means a catchall, as it should.
"*" is distinct from "**".
With syntax highlighting, it's pretty obvious what is going on.
It's backwards compatible (the main reason it's not "tuple(*):args").
*My main problem is: use case? I've had none at all.*
If only 1% of users want it, it's not right to make the 99% change. Saving *one
line and 50 microseconds* per hundred uses of (*/**) is not a valid
argument.And don't make us all change all our code just to satisfy that.
The only argument you can make is readability, but (*/**) is more explicit
than a lookup, just because it's not dependant on position (args/kwargs
argument) and it's always a real tuple and dict.
def tuple(): 1/0
--
http://mail.python.org/mailman/listinfo/python-list
Re: Debugging a difficult refcount issue.
On Saturday, December 17, 2011 11:55:13 PM UTC-8, Paul Rubin wrote: > buck writes: > > I tried to pinpoint this intermediate allocation with a similar > > PyDict_New/LD_PRELOAD interposer, but that isn't working for me[2]. > > Did you try a gdb watchpoint? I didn't try that, since that piece of code is run millions of times, and I don't know the dict-id I'm looking for until after the problem has occurred. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
On Sun, 18 Dec 2011 06:13:37 -0800, Eelco wrote: > Casts or conversions are a runtime concept; im talking about > declarations. That seems to be the source of your confusion. Everything in Python happens at runtime, apart from compilation of source code into byte code. Python doesn't have declarations. Even class and def are statements which happen at runtime, not declarations which happen at compile time. Your proposal will be no different: if it happens, it will happen at runtime. [...] > I guess this use of the term entered my lexicon through the > C# developer team. Either way, you seem to be the only one who does not > grok my intended meaning, so I suggest you try reading it again. I grok your *intended* meaning. I also grok that you are using the wrong words to explain your intended meaning. "head, *tail = iterable" is not a declaration in Python. It is not a type conversion, or a constraint, or a cast. It is an iterator unpacking operation. It is syntactic sugar for something similar to this: tmp = iter(iterable) head = next(tmp) tail = [] try: while True: tail.append(next(tmp)) except StopIteration: pass del tmp The only constraint is on the *input* to the operation: the right hand side object must obey the iterator protocol. The only conversion (if we want to call it such) is that an iterator object is created by the right hand side object. [...] > head, tail = l and head, *tail = l mean something completely different, They are both iterator unpacking, and therefore by definition not "completely different". The first one is syntactic sugar for something like this: tmp = iter(iterable) head = next(tmp) tail = next(tmp) if tmp is not empty: raise exception del tmp and the second as shown earlier. Clearly they are quite similar: the only difference is that in the first case, the right hand side must have exactly two items, while in the second case, the right hand side can have an arbitrary number of items. > and the only difference is a constraint placed on tail, which forces the > semantics to be different; the righthand side, or what is to be > assigned, is identical. Of course one can just regard it as syntactic > sugar for head, tail = unpackheadandtailaslist(l); but the syntactic > sugar achieves that same end through a type constraint on tail. Really. All the words are in English, but I have no understanding of what you are trying to say here. What is unpackheadandtailaslist and how does it differ from actual unpacking in Python? >> You are jumping to conclusions about implementation details which >> aren't supported by the visible behaviour. What evidence do you have >> that iterator unpacking creates a tuple first and then converts it to a >> list? > > You are jumping to conclusions about my opinion which aren't supported > by my visible behaviour. What evidence do you have that I ever even said > any such thing? My evidence was your actual words, quoted in my post, which you deleted in your response. Here they are again: [quote] This changes the semantics from normal unpacking, to unpacking and then repacking all but the head into a list. [end quote] In context, "this changes..." refers to extended iterator unpacking in the form "head, *tail" contrasted with "head, tail =...", and that it generates a list. It may very well be that I have misunderstood you. If you do not intend the meaning that extended tuple unpacking first unpacks to a tuple and then re-packs to a list, then please explain what you did mean. >> > The aim of this PEP, is that this type-constraint syntax is expanded >> > upon. We should be careful here to distinguish with providing >> > optional type constraints throughout python as a whole; this is not >> > our aim. >> >> Iterator unpacking is no more about type constraints than is len(). > > Because you wish to keep nitpicking about my usage of the term 'type > constraint' (even though you have not introduced an alternative term > yourself), or because you actually disagree with the content of my > message? I don't think much about your proposal. I think it is unnecessary, based on a profound misunderstanding of how Python actually operates, badly explained using inappropriate terms, and the syntax you propose is ugly. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
On 18 dec, 18:03, Steven D'Aprano wrote: > On Sun, 18 Dec 2011 06:13:37 -0800, Eelco wrote: > > Casts or conversions are a runtime concept; im talking about > > declarations. That seems to be the source of your confusion. > > Everything in Python happens at runtime, apart from compilation of source > code into byte code. Python doesn't have declarations. Even class and def > are statements which happen at runtime, not declarations which happen at > compile time. Of course it will have runtime effects; and compile/interpret-time effects too. You said as much yourself: 'Everything in Python happens at runtime, apart from compilation of source'. Python *does* have declarations. Even though they may not be called such in the documentation (dunno, havnt checked) the current use of * and ** when not signifying collectiong UNpacking, is an annotation to the declaration of the symbol that comes after it. In this case, a constraint-on / specification-of the type of the object that the variable symbol may bind; a list or tuple, depending on the context. > Your proposal will be no different: if it happens, it will happen at > runtime. At least something we agree upon; all im proposing is an alternative syntax for something thats already there. Lets be pragmatic and agree to disagree on what it is that is already there, or what it ought to be called. Because frankly, this has detracted enough already from what it is I do want to discuss. > [snipped staements of the obvious] > > and the second as shown earlier. Clearly they are quite similar: the only > difference is that in the first case, the right hand side must have > exactly two items, while in the second case, the right hand side can have > an arbitrary number of items. Oh great, you found another semantic hair to split. Yes, they are quite similar. Nonetheless, any python implementation that would confuse the two behaviors would be considered badly bugged. > > and the only difference is a constraint placed on tail, which forces the > > semantics to be different; the righthand side, or what is to be > > assigned, is identical. Of course one can just regard it as syntactic > > sugar for head, tail = unpackheadandtailaslist(l); but the syntactic > > sugar achieves that same end through a type constraint on tail. Really. > > All the words are in English, but I have no understanding of what you are > trying to say here. What is unpackheadandtailaslist and how does it > differ from actual unpacking in Python? I have the impression you are not even trying then. Google 'syntactic sugar'. It means 'semantically identical way of putting things', in short. That tells you everything you need to know about unpackheadandtailaslist: nothing. > >> You are jumping to conclusions about implementation details which > >> aren't supported by the visible behaviour. What evidence do you have > >> that iterator unpacking creates a tuple first and then converts it to a > >> list? > > > You are jumping to conclusions about my opinion which aren't supported > > by my visible behaviour. What evidence do you have that I ever even said > > any such thing? > > My evidence was your actual words, quoted in my post, which you deleted > in your response. > > Here they are again: > > [quote] > This changes the semantics from normal unpacking, to unpacking > and then repacking all but the head into a list. > [end quote] > > In context, "this changes..." refers to extended iterator unpacking in > the form "head, *tail" contrasted with "head, tail =...", and that it > generates a list. > > It may very well be that I have misunderstood you. If you do not intend > the meaning that extended tuple unpacking first unpacks to a tuple and > then re-packs to a list, then please explain what you did mean. Again, where did I say it first unpacks to a tuple? As far as im aware that only happens in the context of a function call. > >> > The aim of this PEP, is that this type-constraint syntax is expanded > >> > upon. We should be careful here to distinguish with providing > >> > optional type constraints throughout python as a whole; this is not > >> > our aim. > > >> Iterator unpacking is no more about type constraints than is len(). > > > Because you wish to keep nitpicking about my usage of the term 'type > > constraint' (even though you have not introduced an alternative term > > yourself), or because you actually disagree with the content of my > > message? > > I don't think much about your proposal. I think it is unnecessary, based > on a profound misunderstanding of how Python actually operates, badly > explained using inappropriate terms, and the syntax you propose is ugly. Which is not an aswer to the question I posed; just an expression of frustration. Its mutual. -- http://mail.python.org/mailman/listinfo/python-list
Re: Debugging a difficult refcount issue.
I don't have any great advice, that kind of issue is hard to pin down. That said, do try using a python compile with --with-debug enabled, with that you can turn your unit tests on and off to pinpoint where the refcounts are getting messed up. It also causes python to use plain malloc()s so valgrind becomes useful. Worst case add assertions and printf()s in the places you think are most janky. -Jack On Sat, Dec 17, 2011 at 11:17 PM, buck wrote: > I'm getting a fatal python error "Fatal Python error: GC object already > tracked"[1]. > > Using gdb, I've pinpointed the place where the error is detected. It is an > empty dictionary which is marked as in-use. This is somewhat helpful since I > can reliably find the memory address of the dict, but it does not help me > pinpoint the issue. I was able to find the piece of code that allocates the > problematic dict via a malloc/LD_PRELOAD interposer, but that code was pure > python. I don't think it was the cause. > > I believe that the dict was deallocated, cached, and re-allocated via > PyDict_New to a C routine with bad refcount logic, then the above error > manifests when the dict is again deallocated, cached, and re-allocated. > > I tried to pinpoint this intermediate allocation with a similar > PyDict_New/LD_PRELOAD interposer, but that isn't working for me[2]. > > How should I go about debugging this further? I've been completely stuck on > this for two days now :( > > [1] http://hg.python.org/cpython/file/99af4b44e7e4/Include/objimpl.h#l267 > [2] > http://stackoverflow.com/questions/8549671/cant-intercept-pydict-new-with-ld-preload > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Question about Reading from text file with Python's Array class
I've been trying to use the Array class to read 32-bit integers from a
file. There is one integer per line and the integers are stored as text.
For problem specific reasons, I only am allowed to read 2 lines (2 32-bit
integers) at a time.
To test this, I made a small sample file (sillyNums.txt) as follows;
109
345
2
1234556
To read this file I created the following test script (trying to copy
something I saw on Guido's blog -
http://neopythonic.blogspot.com/2008/10/sorting-million-32-bit-integers-in-2mb.html
):
import array
assert array.array('i').itemsize == 4
bufferSize = 2
f=open("sillyNums.txt","r")
data = array.array('i')
data.fromstring(f.read(data.itemsize* bufferSize))
print data
The output was nonsense:
array('i', [171520049, 171258931])
I assume this has something to do with my incorrectly specifying how the
various bit/bytes line up. Does anyone know if there's a simple explanation
of how I can do this correctly, or why I can't do it at all?
Thanks,
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Question about Reading from text file with Python's Array class
traveller3141 wrote:
> I've been trying to use the Array class to read 32-bit integers from a
> file. There is one integer per line and the integers are stored as text.
> For problem specific reasons, I only am allowed to read 2 lines (2 32-bit
> integers) at a time.
>
> To test this, I made a small sample file (sillyNums.txt) as follows;
> 109
> 345
> 2
> 1234556
These are numbers in ascii not in binary. To read these you don't have to
use the array class:
from itertools import islice
data = []
with open("sillyNums.txt") as f:
for line in islice(f, 2):
data.append(int(line))
(If you insist on using an array you of course can)
"Binary" denotes the numbers as they are stored in memory and typically used
by lowlevel languages like C. A binary 32 bit integer always consists of 4
bytes. With your code
> To read this file I created the following test script (trying to copy
> something I saw on Guido's blog -
> http://neopythonic.blogspot.com/2008/10/sorting-million-32-bit-integers-
in-2mb.html
> ):
>
> import array
> assert array.array('i').itemsize == 4
>
> bufferSize = 2
>
> f=open("sillyNums.txt","r")
> data = array.array('i')
> data.fromstring(f.read(data.itemsize* bufferSize))
> print data
>
>
> The output was nonsense:
> array('i', [171520049, 171258931])
you are telling Python to interpret the first 8 bytes in the file as two
integers. The first 4 bytes are "1", "0", "9", "\n" (newline) when
interpreted as characters or 49, 48, 57, 10 when looking at the bytes'
numerical values. A 32 bit integer is calculated with
>>> 49+48*2**8+57*2**16+10*2**24
171520049
Looks familiar...
--
http://mail.python.org/mailman/listinfo/python-list
Tumia the first Object-Oriented Internet Directory
Hi, To my knowledge Tumia (http://www.tumia.org) is the first internet directory structured according to the object-oriented paradigm. Currently Tumia is in its baby years. To illustrate the object- oriented concept consider below "Navigate from Earth Global Warming 2000 AD to Mitigating Solar Energy and Back" which is a specific scenario of the use case "Navigate to Related Tumia Instances". Scenario Navigate from Earth Global Warming 2000 AD to Mitigating Solar Energy and Back Precondition: The user has opened http://www.tumia.org . Scenario: 1. The user selects the Tumia Class Climate Change. 2. The system displays http://www.tumia.org/en/directory/en/earth_global_warming_2000_ad_p1.html 3. The user selects the Related Instance Solar Energy. 4. The system displays http://www.tumia.org/en/directory/en/solar_energy_p1.html 5. The user selects the Related Instance Earth Global Warming 2000 AD. 6. The system displays http://www.tumia.org/en/directory/en/earth_global_warming_2000_ad_p1.html I hope as software developers and OO and use case believers you'll find this example to be a promising use of object-orientation and of use cases in the functional analysis discipline of software development. I also hope it shows how important OO is not only in software design but in first instance in functional analysis and thus determining the domain classes of your software design and thus realising low representational gap. Kind Regards, Paka Small -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about Reading from text file with Python's Array class
On 12/18/11 12:33, traveller3141 wrote:
To test this, I made a small sample file (sillyNums.txt) as follows;
109
345
2
1234556
f=open("sillyNums.txt","r")
data = array.array('i')
data.fromstring(f.read(data.itemsize* bufferSize))
print data
The output was nonsense:
array('i', [171520049, 171258931])
I assume this has something to do with my incorrectly specifying how the
various bit/bytes line up. Does anyone know if there's a simple explanation
of how I can do this correctly, or why I can't do it at all?
It reads the bytes directly as if using struct.unpack() as in
>>> data = '109\n345\n2\n123456'
>>> print ' '.join(hex(ord(c))[2:] for c in data)
31 30 39 a 33 34 35 a 32 a 31 32 33 34 35 36
>>> 0x0a393031 # 4 bytes
171520049
It sounds like you want something like
from itertools import islice
a = array.array('i')
a.fromlist(map(int, islice(f, bufferSize)))
which will read the first 2 lines of the file (using islice() on
the file-object and slicing the first 2 items), and map the
string representations into integers, then pass the resulting
list of integer data to the array.array.fromlist() method.
-tkc
--
http://mail.python.org/mailman/listinfo/python-list
Newbie Question: Obtain element from list of tuples
Hi, I'm just starting to learn Python, so please bear with me. I have in my program an object (recs) which is a list of tuples (returned as such by a database query). My question is doubtless a very easy one to answer: Say I want the ninth element in the twentieth tuple put into variable PID, I can do this, bearing in mind that numbering starts at zero: tup = recs[19] PID = tup[8] But there must be an easier way; i.e. to do it in one go without the extra variable. How do I achieve that please? Secondly, I am more than happy to read the fine manuals. If someone could point me in the direction of one or two "for idiots" guides, that would be greatly appreciated. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
On 12/18/2011 2:36, Steven D'Aprano wrote: > The barrier to new keywords in Python is very high. Not going to > happen for something that already has perfectly good syntax already > familiar to Python and Ruby programmers. Might else well try to get C > and Java to stop using "..." (ellipses). I agree to some extent; I did say my suggestion was somewhat an effort in brainstorming. (Though I would point out that, if you accept the premise of this PEP suggestion, "perfectly good" only sort of applies.) > The burden is that you complicate the compiler and reduce the pool of > useful names available to the programmer. To be useful, the keywords need > to be short, meaningful and memorable -- which means they're already used > in code, which you will break needlessly. OTOH, it wouldn't be the first time it was done. For instance, 'with'. > With operators that otherwise would be illegal, the programmer doesn't > need to learn about varargs until they need to. With keywords, the > programmer needs to learn "you can't use varargs or kwargs as variable > names" practically from day 1. Yes, but it's not exactly a hard lesson. I can't think of any time where you'd have ambiguous syntax, so misuse could always produce a good error message. And keyword highlighting is something that basically all editors can do well... so unless you're opposed to using an editor more advanced than Notepad, you'll type in "varargs", it'll turn purple or whatever, and you'll go "oh that's a keyword." > So you're not just adding keywords, you're adding new syntax: something > which looks like a function call, but isn't a function call. Well, almost by definition these proposals consider adding syntax. > I'm going to pose the same question to you I have already posed to Eelco: > in your proposal, what happens if the caller has shadowed the list built- > in? Does argument l become a built-in list, or does it become whatever > type list is currently bound to? > > Some more questions: > > Can varargs accepted arbitrary callables, or only a fixed set of known > types? > > How does this differ from what can be done with annotations? These are questions I don't feel I can answer very well. I was giving my thoughts on what I would do or consider doing with the proposal assuming the fundamental idea is sound. Whether it should be accepted at all is a matter for someone else. :-) Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie Question: Obtain element from list of tuples
On 18 December 2011 19:41, HoneyMonster wrote: > Hi, > > I'm just starting to learn Python, so please bear with me. I have in my > program an object (recs) which is a list of tuples (returned as such by a > database query). > > My question is doubtless a very easy one to answer: Say I want the ninth > element in the twentieth tuple put into variable PID, I can do this, > bearing in mind that numbering starts at zero: > > tup = recs[19] > PID = tup[8] > > But there must be an easier way; i.e. to do it in one go without the > extra variable. How do I achieve that please? Well, you were almost there: pid = recs[19][8] Note: all caps is usually reserved for constants in Python. -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
On 12/18/2011 1:31, Steven D'Aprano wrote: > And rebutted. Modesty[1] prevents me from quoting myself, but here are > some links to searches: > > http://duckduckgo.com/?q=python+asterisk > http://duckduckgo.com/?q=python+* OK, so if you search using the right search engine, you *might* get a link to the Python docs. (As I pointed out in a reply to myself before, you *do* get relevant hits with my Google searches as well, but virtually nothing to the relevant Python documentation.) My thinking is borne out; I asked a friend who didn't know what it did to find out, and he went to Google with the search "python 'starred argument'", which he said led to moderately helpful results, but again none from the actual Python docs. > My normal first place to look for something is Wikipedia. Enjoy it before > SOPA kills it. > > http://en.wikipedia.org/wiki/Asterisk#Programming_languages I might think to look at the Wikipedia article for *Python* (which, by the way, doesn't help); looking at the wikipedia page for *asterisk* wouldn't even enter my mind. > Your search looks overly complicated to me. > > I'm not an expert on Google's syntax, but if you search for "python, > optionally with function", isn't that the same as just searching for > "python" since it will return hits either with or without "function"? Chris Angelico's interpretation is correct: I did four searches, "python function star", "python function asterisk", "python star", and "python asterisk". Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie Question: Obtain element from list of tuples
In article , HoneyMonster wrote: > Hi, > > I'm just starting to learn Python, so please bear with me. I have in my > program an object (recs) which is a list of tuples (returned as such by a > database query). Sounds like a standard database interface -- each tuple represents one row in the query result. Very common. > My question is doubtless a very easy one to answer: Say I want the ninth > element in the twentieth tuple put into variable PID, I can do this, > bearing in mind that numbering starts at zero: > > tup = recs[19] > PID = tup[8] Sure, you could do: PID = recs[19][8] That's shorter, but it probably not better. Presumably, the tuple elements represent columns in the database. It would make the code easier to read if you unpacked the tuple into something with human-readable names: col_1, col_2, col_3, .. col_n = recs[19] and then use the name for the column of interest. A common convention is that when you're unpacking a tuple (or a list, I suppose) and are only interested in some of the elements, you unpack the others into "_". Thus: _, _, _, _, pid, _, _, _ = recs[19] Of course, if you're going to do all that, you probably could have written a better query which returned just the column you were interested in. Instead of "select * from foo", you could have done "select pid from foo" (assuming you're using some SQL-based database). > Secondly, I am more than happy to read the fine manuals. If someone could > point me in the direction of one or two "for idiots" guides, that would > be greatly appreciated. The on-line tutorial is pretty good. http://docs.python.org/tutorial/index.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
On 12/18/2011 8:35, Eelco wrote: > No, its not type *checking*, its type *declaration*. I tried to go to > great lengths to point that out, but it appears I did not do a very > good job :). Type declaration is exactly what I want, and insofar this > syntax has already found adoptation elsewhere, ill consider that a > plus. You say it's found adoption elsewhere, but I think it's that adoption which makes it a *bad* idea, because it does something entirely different in those situations. Other languages are using that syntax for something which is statically checked -- you are proposing that syntax for a dynamic conversion. look pretty familiar... (Not to mention if you just omit the type from the examples above you need another way to distinguish between args and kwargs.) > Yes, one could opt for a syntax where the collection type is optional > and a sensible default is chosen, But to me that would largely defeat > the point; I very much like the added verbosity and explicitness. args- > tuple and kwargs-dict; that just has a much better ring to it than > star-star-kwargs, or whatever other cryptic symbol you use. My problem with it is that it in some sense is forcing me to make a decision I don't care about. Yes, what we have now is less flexible, but I have *never* said "man, I wish this *args parameter were a list instead of a tuple". So at least for me, making me say "args::tuple" or "@tuple args" or whatever is just changing the syntax a bit and adding several more characters for me to type. Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie Question: Obtain element from list of tuples
On Sun, 18 Dec 2011 15:04:13 -0500, Roy Smith wrote: > In article , > HoneyMonster wrote: > >> Hi, >> >> I'm just starting to learn Python, so please bear with me. I have in my >> program an object (recs) which is a list of tuples (returned as such by >> a database query). > > Sounds like a standard database interface -- each tuple represents one > row in the query result. Very common. > >> My question is doubtless a very easy one to answer: Say I want the >> ninth element in the twentieth tuple put into variable PID, I can do >> this, bearing in mind that numbering starts at zero: >> >> tup = recs[19] >> PID = tup[8] > > Sure, you could do: > > PID = recs[19][8] > > That's shorter, but it probably not better. Presumably, the tuple > elements represent columns in the database. It would make the code > easier to read if you unpacked the tuple into something with > human-readable names: > > col_1, col_2, col_3, .. col_n = recs[19] > > and then use the name for the column of interest. A common convention > is that when you're unpacking a tuple (or a list, I suppose) and are > only interested in some of the elements, you unpack the others into "_". > Thus: > > _, _, _, _, pid, _, _, _ = recs[19] > > Of course, if you're going to do all that, you probably could have > written a better query which returned just the column you were > interested in. Instead of "select * from foo", you could have done > "select pid from foo" (assuming you're using some SQL-based database). > >> Secondly, I am more than happy to read the fine manuals. If someone >> could point me in the direction of one or two "for idiots" guides, that >> would be greatly appreciated. > > The on-line tutorial is pretty good. > http://docs.python.org/tutorial/index.html Thanks, Arnaud and Roy. I had no idea it could be so easy. I think I rather like Python! OK, I'll change PID to pid if that's best practice. Yes, it's an SQL-based database, PostgreSQL actually. I'm using psycopg2 to access it and wxGlade to construct the GUI interface. It all seems to be progressing very smoothly. Thanks again. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie Question: Obtain element from list of tuples
In article , HoneyMonster wrote: > I think I rather like Python! +1 QOTD? -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie Question: Obtain element from list of tuples
On Mon, Dec 19, 2011 at 6:41 AM, HoneyMonster wrote:
> My question is doubtless a very easy one to answer: Say I want the ninth
> element in the twentieth tuple put into variable PID, I can do this,
> bearing in mind that numbering starts at zero:
>
> tup = recs[19]
> PID = tup[8]
>
> But there must be an easier way; i.e. to do it in one go without the
> extra variable. How do I achieve that please?
The specific answer has already been given, but I'd like to fill in
the generality. In Python, everything's an object; if you can do
something with a variable, you can do it with an expression too. I
don't know what your function call is to obtain your record list, but
imagine it's:
recs = conn.query("SELECT * FROM some_table")
Then you can actually do all of this in a single statement. It's not
usually what you'll want to do, but this is legal:
pid = conn.query("SELECT * FROM some_table")[19][8]
If you're absolutely certain that you'll always get precisely one
value from a query, this becomes rather more useful:
mode = conn.query("SELECT mode FROM config WHERE id=5")[0][0]
In any case: You can work with a function's return value directly,
without first storing it in a temporary variable.
Hope that helps!
Chris Angelico
--
http://mail.python.org/mailman/listinfo/python-list
Re: Newbie Question: Obtain element from list of tuples
In article ,
Chris Angelico wrote:
> If you're absolutely certain that you'll always get precisely one
> value from a query, this becomes rather more useful:
>
> mode = conn.query("SELECT mode FROM config WHERE id=5")[0][0]
Although, if you're going to do that, you might as well take advantage
of the fetchone() method that most Python database APIs have and
eliminate one of the indexes. Typical code would be something like:
cursor.execute("SELECT mode FROM config WHERE id=5")
mode = cursor.fetchone()[0]
If you're going to be doing any database work in Python, you should be
familiar with the Python Database API Specification,
http://www.python.org/dev/peps/pep-0249/. Most of the vendor-specific
database modules have interfaces which hold pretty close to the style
described there.
You might also want to explore SQL_Alchemy. I personally find it
difficult and painful to work with, but it does have the powerful
advantage that it abstracts away all the vendor-specific differences
between databases.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Newbie Question: Obtain element from list of tuples
On Mon, 19 Dec 2011 07:51:08 +1100, Chris Angelico wrote:
> On Mon, Dec 19, 2011 at 6:41 AM, HoneyMonster
> wrote:
>> My question is doubtless a very easy one to answer: Say I want the
>> ninth element in the twentieth tuple put into variable PID, I can do
>> this, bearing in mind that numbering starts at zero:
>>
>> tup = recs[19]
>> PID = tup[8]
>>
>> But there must be an easier way; i.e. to do it in one go without the
>> extra variable. How do I achieve that please?
>
> The specific answer has already been given, but I'd like to fill in the
> generality. In Python, everything's an object; if you can do something
> with a variable, you can do it with an expression too. I don't know what
> your function call is to obtain your record list, but imagine it's:
>
> recs = conn.query("SELECT * FROM some_table")
>
> Then you can actually do all of this in a single statement. It's not
> usually what you'll want to do, but this is legal:
>
> pid = conn.query("SELECT * FROM some_table")[19][8]
>
> If you're absolutely certain that you'll always get precisely one value
> from a query, this becomes rather more useful:
>
> mode = conn.query("SELECT mode FROM config WHERE id=5")[0][0]
>
> In any case: You can work with a function's return value directly,
> without first storing it in a temporary variable.
>
> Hope that helps!
Thanks, Chris. Actually I had simplified the question somewhat. The
actuality is indeed - as you suspected - that recs = conn.query("SELECT *
FROM some_table") but I am then using the recs object to populate a (non
editable) wxGrid.
When the user selects a row and clicks a button, I am using:
pos = self.grid_1.GetGridCursorRow() to establish which tuple in recs is
involved, and then pid = recs[pos][4] to determine the key value (I
suspected that accessing recs directly would be more efficient that
trying to determine the wxGrid column value, and in any case the pid is
in recs but not in the wxGrid).
I trust this all makes sense. Thanks again.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Newbie Question: Obtain element from list of tuples
On Mon, Dec 19, 2011 at 9:55 AM, HoneyMonster wrote:
> When the user selects a row and clicks a button, I am using:
> pos = self.grid_1.GetGridCursorRow() to establish which tuple in recs is
> involved, and then pid = recs[pos][4] to determine the key value (I
> suspected that accessing recs directly would be more efficient that
> trying to determine the wxGrid column value, and in any case the pid is
> in recs but not in the wxGrid).
Yep, this looks like a sensible way to do it!
I would recommend, though, that you avoid "magic numbers" - the
process ID might happen to be in cell 4, but what if your column list
changes? This is especially problematic when you use "select * from
table", because changes outside your code can break things.
There's two solutions. One is to carefully match your SELECT statement
to a set of constants:
exec("SELECT FOO,BAR,QUUX,ASDF,PID,WHATEVER FROM table")
FOO,BAR,QUUX,ASDF,PID,WHATEVER,*_=range(20) # Cool trick to avoid
having to count the columns
But a better way is to let the database handle it. Check your
interface library to see if you can have it return dictionaries or
objects instead of tuples - then you could use:
pid = recs[pos]["pid"]
# or
pid = recs[pos]->pid
which avoids the need to count columns at all.
Other than that, though, yep - your code concept looks fine.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
On Dec 17, 10:52 pm, buck wrote: > [...] > As for the separator, let's examine the available ascii punctuation. > Excluding valid variable characters, whitespace, and operators, we have: > > ! -- ok. No, there are better uses for that char. > " -- can't use this. Would look like a string. > # -- no. Would looks like a comment. > $ -- ok. No, there are better uses for that char. > : -- ok, maybe. Seems confusing in a colon-terminated statement. dear god no! > ; -- no, just no. > ? -- ok. No, there are better uses for that char. > @ -- ok. YES! -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
On Dec 17, 11:33 pm, Evan Driscoll wrote: > On 12/17/2011 22:52, buck wrote:> Try these on for size. > > > head, @tuple tail = sequence > > def foo(@list args, @dict kwargs): pass > > foo(@args, @kwargs) > > > For backward compatibility, we could say that the unary * is identical to > > @list and unary ** is identical to @dict. > > I like this idea much more than the original one. +1. I will second that! Eelco has the CORRECT idea, but the WRONG syntax! -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
On Dec 18, 8:35 am, Eelco wrote: > On Dec 18, 6:33 am, Evan Driscoll wrote: > Good point; technically the askeriskes could be kept for backwards > compatibility, but that would break 'there should only be one way to > do it'. I believe it's high time for the upper society of this community to realize that the small breaks in backward compatibility in Python 3000 were only the beginning. Python is evolving past even what Guido could have dreamed. He can not hold the reins of this unwieldy beast any longer. -- http://mail.python.org/mailman/listinfo/python-list
Re: Make a small function thread safe
On 18 December 2011 19:52, RangerElf wrote: > Which is why the original .acquire() ... .release() idiom was wrong, this > would better express the intent: > > try: > lock.acquire() > shared_container.append(...) > finally: > lock.release() > No - this is very bad. The lock must be acquired outside the try: - otherwise if an exception is thrown while acquiring, you will try to release a lock that you have not acquired. Which again is why using with is a much better option - you can't make this kind of mistake. Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
On Sun, 18 Dec 2011 13:47:46 -0600, Evan Driscoll wrote: [...] > so unless you're opposed to using an editor more > advanced than Notepad, you'll type in "varargs", it'll turn purple or > whatever, and you'll go "oh that's a keyword." Not everybody uses editors more advanced than Notepad. Even those who do may not have an editor that understands Python keywords, or has an obsolete list of keywords (my editor of choice doesn't know about NotImplementedError). Or they're ssh'ed into a customer's server half-way across the world and using `ed` because that's the only thing available. The point is not that there can never been more keywords in Python, but that the burden of proof is on those asking for new keywords. By default, the status quo wins: http://www.boredomandlaziness.org/2011/02/status-quo-wins-stalemate.html -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Debugging a difficult refcount issue.
Thanks Jack. I think printf is what it will come down to. I plan to put a little code into PyDict_New to print the id and the line at which it was allocated. Hopefully this will show me all the possible suspects and I can figure it out from there. I hope figuring out the file and line-number from within that code isn't too hard. On Sunday, December 18, 2011 9:52:46 AM UTC-8, Jack Diederich wrote: > I don't have any great advice, that kind of issue is hard to pin down. > That said, do try using a python compile with --with-debug enabled, > with that you can turn your unit tests on and off to pinpoint where > the refcounts are getting messed up. It also causes python to use > plain malloc()s so valgrind becomes useful. Worst case add assertions > and printf()s in the places you think are most janky. > > -Jack > > On Sat, Dec 17, 2011 at 11:17 PM, buck wrote: > > I'm getting a fatal python error "Fatal Python error: GC object already > > tracked"[1]. > > > > Using gdb, I've pinpointed the place where the error is detected. It is an > > empty dictionary which is marked as in-use. This is somewhat helpful since > > I can reliably find the memory address of the dict, but it does not help me > > pinpoint the issue. I was able to find the piece of code that allocates the > > problematic dict via a malloc/LD_PRELOAD interposer, but that code was pure > > python. I don't think it was the cause. > > > > I believe that the dict was deallocated, cached, and re-allocated via > > PyDict_New to a C routine with bad refcount logic, then the above error > > manifests when the dict is again deallocated, cached, and re-allocated. > > > > I tried to pinpoint this intermediate allocation with a similar > > PyDict_New/LD_PRELOAD interposer, but that isn't working for me[2]. > > > > How should I go about debugging this further? I've been completely stuck on > > this for two days now :( > > > > [1] http://hg.python.org/cpython/file/99af4b44e7e4/Include/objimpl.h#l267 > > [2] > > http://stackoverflow.com/questions/8549671/cant-intercept-pydict-new-with-ld-preload > > -- > > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
On Dec 18, 7:26 pm, Steven D'Aprano wrote: > Not everybody uses editors more advanced than Notepad. And they have no excuse for NOT using a better one. Well, except for a "foolish consistency" that is! > Even those who do > may not have an editor that understands Python keywords, or has an > obsolete list of keywords (my editor of choice doesn't know about > NotImplementedError). Are you kidding me? Any editor that is not smart enough to do... >>> import keyword >>> pyKeyWords = keyword.kwlist ... needs to be thrown out the window. And let's not forget that Python even ships with an IDE called IDLE. As poorly written as IDLE's code may be, at least it is smart enough to find the current keyword list. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
Evan Driscoll wrote: > My problem with it is that it in some sense is forcing me to make a > decision I don't care about. Yes, what we have now is less flexible, but > I have *never* said "man, I wish this *args parameter were a list > instead of a tuple". And if you _did_, then one of the first lines in your function would be: args = list(args) Which is obvious to everyone, doesn't modify existing behaviour, doesn't force everyone without a fetish for change to add unnecessary cruft to their function signature... Except, OMG, list() is RETURNING A LIST, which is an OBVIOUS type constraint. I propose that: args = @set list(args) Will coerce args into a list and then give me a set in return. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie Question: Obtain element from list of tuples
Roy Smith wrote:
> A common convention
> is that when you're unpacking a tuple (or a list, I suppose) and are
> only interested in some of the elements, you unpack the others into "_".
> Thus:
>
> _, _, _, _, pid, _, _, _ = recs[19]
Pre-namedtuple, I used to like using named slices for this:
cPID = slice(19)
pid = recs[cPID]
cHostPort = slice(99,100)
host, port = recs[cHostPort]
etc.
The suggestions of having your query return a dictionary where
possible are the most ideal, but if it's not possible you can always
wrap the result tuple in a namedtuple:
from collections import namedtuple
Staff = namedtuple('Staff',
['firstname','lastname','age','position'])
sql_result = ('John', 'Example', '30', 'Dummy')
staff_record = Staff(sql_result)
print staff_record.firstname, staff_record.age
--
http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
On 17Dec2011 22:43, Evan Driscoll wrote: | On 12/17/2011 21:42, Chris Angelico wrote: | > Welcome to the list! If you're curious as to what's happened, check | > the archives: | > http://mail.python.org/pipermail/python-list/ | Thanks! Incidentally, is there a good way to respond to the original | post in this thread, considering it wasn't delivered to me? Personally, when I join a mailing list I download the archives and unpack them into my mail folder for that list. Then I can reply! (I actually do this for search purposes). Cheers, -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ You can't have everything... where would you put it? - Charles Robinson, cr0...@medtronic.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
On Sun, Dec 18, 2011 at 6:26 PM, Steven D'Aprano wrote: > On Sun, 18 Dec 2011 13:47:46 -0600, Evan Driscoll wrote: > > [...] >> so unless you're opposed to using an editor more >> advanced than Notepad, you'll type in "varargs", it'll turn purple or >> whatever, and you'll go "oh that's a keyword." > > Not everybody uses editors more advanced than Notepad. Even those who do > may not have an editor that understands Python keywords, or has an > obsolete list of keywords (my editor of choice doesn't know about > NotImplementedError). Probably because NotImplementedError is not a keyword. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie Question: Obtain element from list of tuples
On Sun, 18 Dec 2011 18:35:47 -0800, alex23 wrote: > Pre-namedtuple, I used to like using named slices for this: > > cPID = slice(19) > pid = recs[cPID] You know, that is an incredibly simple thing and yet it never dawned on me before now. Thank you for sharing that. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
On Sun, 18 Dec 2011 20:00:59 -0700, Ian Kelly wrote: > On Sun, Dec 18, 2011 at 6:26 PM, Steven D'Aprano > wrote: >> On Sun, 18 Dec 2011 13:47:46 -0600, Evan Driscoll wrote: >> >> [...] >>> so unless you're opposed to using an editor more advanced than >>> Notepad, you'll type in "varargs", it'll turn purple or whatever, and >>> you'll go "oh that's a keyword." >> >> Not everybody uses editors more advanced than Notepad. Even those who >> do may not have an editor that understands Python keywords, or has an >> obsolete list of keywords (my editor of choice doesn't know about >> NotImplementedError). > > Probably because NotImplementedError is not a keyword. Poor choice of words on my part. My editor colours built-ins like ValueError, TypeError, len, sum, etc., but not NotImplementedError. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
On Mon, Dec 19, 2011 at 1:23 PM, alex23 wrote: > Except, OMG, list() is RETURNING A LIST, which is an OBVIOUS type > constraint. I propose that: > > args = @set list(args) > > Will coerce args into a list and then give me a set in return. Point to note: list,set = set,list # Request a death sentence from the next maintainer is perfectly legal code. Now, what does your "args=" line do? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: PyCon US 2012 sprints
2011/12/17 Ricardo Bánffy : > Hi folks. > > Next March I'm planning to attend PyCon US (for the first time) and > stay for the sprints. I am not sure how they work, however. Are there > any "first-timer guide to PyCon sprints"? I don't know of any such guide, but here's what usually happens: 1. Right after the closing of the conference days on Sunday, late in the afternoon, there will be a chance for all projects who plan to host sprints to get on stage and talk for a minute about who they are, what their project is, and what they'll be sprinting on. You might hear something like this: "Hi I'm Brian and I'll be hosting a sprint on foo project. We're going to be working on x, y, and z functionality using a lot of a, b, and c libraries. Come check it out of you're interested. We've got plenty of stuff for first timers" 2. At the entrance to wherever the sprints will be there will be a board listing what projects are sprinting in what areas. The last few years we've taken over numerous rooms, so that board acted as a map to know what was going on in what room. 3. I don't yet know how the sprints will be laid out this year since it's a new hotel and location, but if its anything like last year, each room will have several projects working inside it. It's quite normal to just walk in and say "hey where's the blah blah sprint at?", then see they're over in the corner. Everyone has been really friendly in my experience, and a lot of people bounce back and forth between rooms for a lot of reasons, so ask if you don't know where you're going or who you're looking for. 4. Hack on some fun stuff and meet some new people. It's a bit early for the 2012 sprint page to be up and populated, but it'll happen soon enough. The 2011 page is here (http://us.pycon.org/2011/sprints/) and the list of some (but not all) of the sprints and their attendees here: http://us.pycon.org/2011/sprints/projects/ It's really relaxed and a lot of fun. It's one of my favorite parts of the PyCon experience. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie Question: Obtain element from list of tuples
"Steven D'Aprano" wrote in message news:4eeea8eb$0$11091$c3e8...@news.astraweb.com... On Sun, 18 Dec 2011 18:35:47 -0800, alex23 wrote: Pre-namedtuple, I used to like using named slices for this: cPID = slice(19) pid = recs[cPID] You know, that is an incredibly simple thing and yet it never dawned on me before now. Thank you for sharing that. I also like it, but it does not work quite so simply for me. row = tuple(range(20)) cPID = slice(15) pid = row[cPID] pid (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14) This works - row = tuple(range(20)) cPID = slice(15, 16) pid, = row[cPID] # note the trailing comma pid 15 Still nice, but not quite so elegant. Am I missing something? Frank Millman -- http://mail.python.org/mailman/listinfo/python-list
Re: Make a small function thread safe
On Sun, Dec 18, 2011 at 6:27 PM, Tim Delaney wrote: > On 18 December 2011 19:52, RangerElf wrote: >> >> Which is why the original .acquire() ... .release() idiom was wrong, this >> would better express the intent: >> >> try: >> lock.acquire() >> shared_container.append(...) >> finally: >> lock.release() > > > No - this is very bad. The lock must be acquired outside the try: - > otherwise if an exception is thrown while acquiring, you will try to release > a lock that you have not acquired. > > Which again is why using with is a much better option - you can't make this > kind of mistake. Well, not unless you make the same mistake in the context manager itself. from contextlib import contextmanager @contextmanager def bad_context_manager(lock): try: lock.acquire() yield finally: lock.release() class Lock(object): def __init__(self): self.is_locked = False def acquire(self): assert False def release(self): assert self.is_locked, "Tried to release lock without acquiring it" with bad_context_manager(Lock()): pass Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ return self.gen.next() File "", line 7, in bad_context_manager File "", line 7, in release AssertionError: Tried to release lock without acquiring it Perhaps a (small) reason to avoid the contextmanager decorator and implement __enter__ and __exit__ instead. -- http://mail.python.org/mailman/listinfo/python-list
