Strings in python extensions
Has anyone noticed that the type=string variables passed to python extensions have literal quotes in them? For instance the number nodes (dots.py) example doesn't really work in the latest snapshot I downloaded because the sizes are getting set to things like '"20"' instead of just '20'
--bb
I noticed this, too. Ted, I assume this is caused by your changes? Are you planning to fix it?
On 9/25/07, Bill Baxter <wbaxter@...400...> wrote:
Has anyone noticed that the type=string variables passed to python extensions have literal quotes in them? For instance the number nodes (dots.py) example doesn't really work in the latest snapshot I downloaded because the sizes are getting set to things like '"20"' instead of just '20'
--bb
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Well,
I thought I had fixed it. Let me look some more. Is this a platform specific thing? There were double quotes, and now they're singular, but I thought that Python would want '--myparam="variable that is long"' as it's parameter. Is that not correct?
--Ted
On Tue, 2007-09-25 at 01:07 -0300, bulia byak wrote:
I noticed this, too. Ted, I assume this is caused by your changes? Are you planning to fix it?
On 9/25/07, Bill Baxter <wbaxter@...400...> wrote:
Has anyone noticed that the type=string variables passed to python extensions have literal quotes in them? For instance the number nodes (dots.py) example doesn't really work in the latest snapshot I downloaded because the sizes are getting set to things like '"20"' instead of just '20'
--bb
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mon, 2007-09-24 at 23:16 -0700, Ted Gould wrote:
I thought I had fixed it. Let me look some more. Is this a platform specific thing? There were double quotes, and now they're singular, but I thought that Python would want '--myparam="variable that is long"' as it's parameter. Is that not correct?
No, definitely happens on Linux too. I guess the shell must have gotten rid of all those quotes before. Wow. I'll test and commit a fix.
--Ted
Ted Gould wrote:
No, definitely happens on Linux too. I guess the shell must have gotten rid of all those quotes before. Wow. I'll test and commit a fix.
I think Johan added some extra quotes to combat an issue with quoting file paths. But now we certainly have them in too many places. I've been trying to think up a proper fix on the python side, but have been running short of brain cycles. If there is a proper fix on the Inkscape side that would be great. I'm sure there are platform dependant (and shell dependant issues) here so it probably is complicated.
Aaron
On Tue, 2007-09-25 at 06:19 -0500, Aaron Spike wrote:
Ted Gould wrote:
No, definitely happens on Linux too. I guess the shell must have gotten rid of all those quotes before. Wow. I'll test and commit a fix.
I think Johan added some extra quotes to combat an issue with quoting file paths. But now we certainly have them in too many places. I've been trying to think up a proper fix on the python side, but have been running short of brain cycles. If there is a proper fix on the Inkscape side that would be great. I'm sure there are platform dependant (and shell dependant issues) here so it probably is complicated.
Well, we're not using the shell anymore. So that removes one variable. I'm guessing at this point that Python is looking at '--myvar="bob"' and doing a split on '=' and then returning the right hand side. Do you know if that's true?
--Ted
Ted Gould wrote:
Well, we're not using the shell anymore. So that removes one variable. I'm guessing at this point that Python is looking at '--myvar="bob"' and doing a split on '=' and then returning the right hand side. Do you know if that's true?
We're using the optparse module from the python standard library. Documentation can be found at:
http://www.python.org/doc/2.4/lib/module-optparse.html
Aaron Spike
On Tue, 2007-09-25 at 11:40 -0500, Aaron Spike wrote:
Ted Gould wrote:
Well, we're not using the shell anymore. So that removes one variable. I'm guessing at this point that Python is looking at '--myvar="bob"' and doing a split on '=' and then returning the right hand side. Do you know if that's true?
We're using the optparse module from the python standard library. Documentation can be found at:
Thanks for the info, I can't find where it says exactly how it handles the data -- but I'm pretty sure it's leaving the quotes in now.
Thanks, Ted
On Tue, 2007-09-25 at 13:01 +0900, Bill Baxter wrote:
Has anyone noticed that the type=string variables passed to python extensions have literal quotes in them? For instance the number nodes (dots.py) example doesn't really work in the latest snapshot I downloaded because the sizes are getting set to things like '"20"' instead of just '20'
Don't know if this is related, but in the Function Plotter effect, all the entries in the Range and Sampling tab are now ignored.
Tav
participants (5)
-
Aaron Spike -
Bill Baxter -
bulia byak -
Tavmjong Bah -
Ted Gould