@JimBiardCics wrote:
Actually, I know a LOT more about Python than I do about netcdf, HDF, or CF.
And I'm afraid you have it a bit confused. This is kind of off-topic, but for
clarities sake:
> Python 3 is not the same as python 2.
Very True, and a source of much confusion.
> In Python 2
I'm getting double messages -- I think we may have a feedback loop between
gitHub and the list .
But anyway:
> Hmmm. Chris, I think you are implying a problem that does not exist.
I hope that's true, Sorry if I stirred up confusion.
But I was responding to a comment about ASCII vs UTF-8,
Chris,
Python 3 is not the same as python 2. In Python 2 there were two types — str
(ASCII) and unicode (by default UTF-8). In Python 3 there is only str, and by
default it holds UTF-8 unicode (there's lots of subtly that I'm glossing over
here, but this is what it boils down to). It bit me
Hmmm. Chris, I think you are implying a problem that does not exist. I do not
think CF has ever restricted the use of UTF-8 in free text within attributes.
I suspect there are many UTF-8 attribute examples in the wild, though I do not
have one up my sleeve right now. Please correct me if
@Dave-Allured I approve of your proposal. I think we pretty much have no choice
but to allow UTF-8 as a baseline to start with, but there clearly are larger
issues to be resolved. (I say "no choice" because, for example, constraining to
ASCII in python 3 is a bit complicated.)
--
You are
@Dave-Allured That sounds OK to me, whatever does get adopted, should probably
be pretty explicit about what is "not allowed".
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
@DocOtak, thanks for restarting this. In light of past difficulties, I move to
split the issue.
I think it would be possible to break out the more difficult parts of this
topic into new and separate issues. I suggest that this issue #141 be narrowed
to only a single essential ingredient:
So now that [string variables have
landed](https://github.com/cf-convention/cf-conventions/pull/140), I want to
bring some attention to this issue again. Some updates I've learned about:
* Because strings are allowed in variables, some are assuming that string
attributes are allowed by CF 1.8,
Yes, thanks for moderating, David.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/174#issuecomment-598784783
This list forwards relevant notifications from Github. It
Thanks David, I believe that would be very helpful. We have agreed to change it
from a `defect` to an `enhancement`, but I don't appear to have the permission
needed to effect that change, so please make that switch if you can.
--
You are receiving this because you are subscribed to this
As far as I can tell this issue has no moderator as yet. I would be happy to
take this on, if everyone else is OK with that. I will try to collate a summary
of the points raised, sometime (hopefully early) next week.
Thanks, David
--
You are receiving this because you are subscribed to this
Speaking as someone that has been trying to make sense of very diverse CF files
with nothing but the CF-Convention in my hand, I have to say the fact that
dimension coordinates can be identified by name and dimension being the same is
a good thing.
It is very hard to correctly identify, for
12 matches
Mail list logo
