To write headers once with different values in separate row in CSV

kbtyo ahlusar.ahluwalia at gmail.com
Wed Jun 24 08:52:58 EDT 2015


On Wednesday, June 24, 2015 at 8:38:24 AM UTC-4, Steven D'Aprano wrote:
> On Wed, 24 Jun 2015 09:37 pm, kbtyo wrote:
> 
> > On Tuesday, June 23, 2015 at 9:50:50 PM UTC-4, Steven D'Aprano wrote:
> >> On Wed, 24 Jun 2015 03:15 am, Sahlusar wrote:
> >> 
> >> > That is not the underlying issue. Any thoughts or suggestions would be
> >> > very helpful.
> >> 
> >> 
> >> Thank you for spending over 100 lines to tell us what is NOT the
> >> underlying issue. I will therefore tell you what is NOT the solution to
> >> your problem (whatever it is, since I can't tell). The solution is NOT to
> >> squeeze lemon juice into your keyboard.
> >> 
> >> If someday you feel like telling us what the issue actually IS, instead
> >> of what it IS NOT, then perhaps we will have a chance to help you find a
> >> solution.
> >> 
> >> 
> >> 
> >> --
> >> Steven
> > 
> > Curious - what should I have provided? 
> 
> To start with, you should tell us what is the problem you are having. You
> gave us some code, and then said "That is not the underlying issue". Okay,
> so what is the underlying issue? What is the problem you want help solving?
> 
> In another post, you responded to John Gordon's question:
> 
>     # John
>     Have you tried creating some dummy data by hand and seeing 
>     how makerows() handles it?
> 
> 
> by answering:
> 
>     Yes I did do this.
> 
> 
> Okay. What was the result? Do you want us to guess what result you got?
> 
> 
> John also suggested that you provide sample data, and an implementation of
> flatten_dict, and your answer is:
> 
>     Yes, unfortunately, due to NDA protocols I cannot share this.
> 
> 
> You don't have to provide your *actual* data. You can provide *sample* data,
> that does not contain any of your actual confidential values. If your XML
> file looks like this:
> 
> <?xml version="1.0"?>
> <catalog>
>    <book id="bk101">
>       <author>Gambardella, Matthew</author>
>       <title>XML Developer's Guide</title>
>       <genre>Computer</genre>
>       <price>44.95</price>
>       <publish_date>2000-10-01</publish_date>
>       <description>An in-depth look at creating applications 
>       with XML.</description>
>    </book>
> </catalog>
> 
> 
> you can replace the data:
> 
> <?xml version="1.0"?>
> <catalog>
>    <book id="1111">
>       <author>Smith, John</author>
>       <title>ABCDEF</title>
>       <genre>Widgets</genre>
>       <price>9999.99</price>
>       <publish_date>1900-01-01</publish_date>
>       <description>blah blah blah blah</description>
>    </book>
> </catalog>
> 
> 
> You can even change the tags:
> 
> 
> <?xml version="1.0"?>
> <whatzit>
>    <spam id="1111">
>       <a>Smith, John</a>
>       <b>ABCDEF</b>
>       <c>Widgets</c>
>       <d>9999.99</d>
>       <e>1900-01-01</e>
>       <f>blah blah blah blah</f>
>    </spam>
> </whatzit>
> 
> 
> If you're still worried that the sample XML has the same structure as your
> real data, you can remove some fields and add new ones:
> 
> <?xml version="1.0"?>
> <whatzit>
>    <spam id="1111">
>       <b>ABCDEF</b>
>       <d>9999.99</d>
>       <e>1900-01-01</e>
>       <z>fe fi fo fum</z>
>       <f>blah blah blah blah</f>
>    </spam>
> </whatzit>
> 
> 
> If you can't share the flatten_dict() function, either: 
> 
> (1) get permission to share it from your manager or project leader.
> flatten_dict is not a trade secret or valuable in any way, and
> half-competent Python programmer can probably come up with two or three
> different ways to flatten a dict in five minutes. They're all going to look
> more or less the same, because there's only so many ways to flatten a dict.
> 
> (2) Or accept that we can't help you, and deal with it on your own.
> 
> 
> 
> > Detailed and constructive feedback 
> > (like your reply to my post regarding importing functions) is more useful
> > than to "squeeze lemon juice" into one's keyboard.
> 
> Of course. That is why I said it was NOT the solution. Don't waste your time
> squeezing lemon juice over your keyboard, it won't solve your problem.
> 
> But you can't expect us to guess what your problem is, or debug code we
> can't see, or read your mind and understand your data.
> 
> Before you ask any more questions, please read this:
> 
> http://sscce.org/
> 
> 
> 
> -- 
> Steven



On Wednesday, June 24, 2015 at 8:38:24 AM UTC-4, Steven D'Aprano wrote:
> On Wed, 24 Jun 2015 09:37 pm, kbtyo wrote:
> 
> > On Tuesday, June 23, 2015 at 9:50:50 PM UTC-4, Steven D'Aprano wrote:
> >> On Wed, 24 Jun 2015 03:15 am, Sahlusar wrote:
> >> 
> >> > That is not the underlying issue. Any thoughts or suggestions would be
> >> > very helpful.
> >> 
> >> 
> >> Thank you for spending over 100 lines to tell us what is NOT the
> >> underlying issue. I will therefore tell you what is NOT the solution to
> >> your problem (whatever it is, since I can't tell). The solution is NOT to
> >> squeeze lemon juice into your keyboard.
> >> 
> >> If someday you feel like telling us what the issue actually IS, instead
> >> of what it IS NOT, then perhaps we will have a chance to help you find a
> >> solution.
> >> 
> >> 
> >> 
> >> --
> >> Steven
> > 
> > Curious - what should I have provided? 
> 
> To start with, you should tell us what is the problem you are having. You
> gave us some code, and then said "That is not the underlying issue". Okay,
> so what is the underlying issue? What is the problem you want help solving?
> 
> In another post, you responded to John Gordon's question:
> 
>     # John
>     Have you tried creating some dummy data by hand and seeing 
>     how makerows() handles it?
> 
> 
> by answering:
> 
>     Yes I did do this.
> 
> 
> Okay. What was the result? Do you want us to guess what result you got?
> 
> 
> John also suggested that you provide sample data, and an implementation of
> flatten_dict, and your answer is:
> 
>     Yes, unfortunately, due to NDA protocols I cannot share this.
> 
> 
> You don't have to provide your *actual* data. You can provide *sample* data,
> that does not contain any of your actual confidential values. If your XML
> file looks like this:
> 
> <?xml version="1.0"?>
> <catalog>
>    <book id="bk101">
>       <author>Gambardella, Matthew</author>
>       <title>XML Developer's Guide</title>
>       <genre>Computer</genre>
>       <price>44.95</price>
>       <publish_date>2000-10-01</publish_date>
>       <description>An in-depth look at creating applications 
>       with XML.</description>
>    </book>
> </catalog>
> 
> 
> you can replace the data:
> 
> <?xml version="1.0"?>
> <catalog>
>    <book id="1111">
>       <author>Smith, John</author>
>       <title>ABCDEF</title>
>       <genre>Widgets</genre>
>       <price>9999.99</price>
>       <publish_date>1900-01-01</publish_date>
>       <description>blah blah blah blah</description>
>    </book>
> </catalog>
> 
> 
> You can even change the tags:
> 
> 
> <?xml version="1.0"?>
> <whatzit>
>    <spam id="1111">
>       <a>Smith, John</a>
>       <b>ABCDEF</b>
>       <c>Widgets</c>
>       <d>9999.99</d>
>       <e>1900-01-01</e>
>       <f>blah blah blah blah</f>
>    </spam>
> </whatzit>
> 
> 
> If you're still worried that the sample XML has the same structure as your
> real data, you can remove some fields and add new ones:
> 
> <?xml version="1.0"?>
> <whatzit>
>    <spam id="1111">
>       <b>ABCDEF</b>
>       <d>9999.99</d>
>       <e>1900-01-01</e>
>       <z>fe fi fo fum</z>
>       <f>blah blah blah blah</f>
>    </spam>
> </whatzit>
> 
> 
> If you can't share the flatten_dict() function, either: 
> 
> (1) get permission to share it from your manager or project leader.
> flatten_dict is not a trade secret or valuable in any way, and
> half-competent Python programmer can probably come up with two or three
> different ways to flatten a dict in five minutes. They're all going to look
> more or less the same, because there's only so many ways to flatten a dict.
> 
> (2) Or accept that we can't help you, and deal with it on your own.
> 
> 
> 
> > Detailed and constructive feedback 
> > (like your reply to my post regarding importing functions) is more useful
> > than to "squeeze lemon juice" into one's keyboard.
> 
> Of course. That is why I said it was NOT the solution. Don't waste your time
> squeezing lemon juice over your keyboard, it won't solve your problem.
> 
> But you can't expect us to guess what your problem is, or debug code we
> can't see, or read your mind and understand your data.
> 
> Before you ask any more questions, please read this:
> 
> http://sscce.org/
> 
> 
> 
> -- 
> Steven

Thanks for the feedback. To be quite honest with you, I have just started a new position as a data engineer after switching careers from secondary education. This feedback will help me adapt to this community. Thank you again for your continued support. 



More information about the Python-list mailing list