With my project that uses attrs, I'm defining some fields with a leading underscore so that I can make a property with the same name minus the leading underscore. I'm doing this because I'm adding some simple logic to the setter method for when the value get's set (very important).
I was wondering if there is a way I could remove the leading underscores from the __repr__.
I couldn't find anything about this after some google searching, so I figure there might be a way attrs helps you handle data being set? I'm not sure though.
If anyone could recommend me some solutions or ways they'd tackle this problem, I'd appreciate it very much!
Thanks!
Customizing the name of fields is not supported unfortunately. You can pass a callable for attr.ib/attrs.field’s repr, but that only affects the value.
Related
Problem
I'm writing an essay/documentation about an application. Within this doc there are a lot of code-words which I want to be highlighted using a different font. Currently I work with:
{\fontfamily{cmtt}\selectfont SOME-KEY-WORD}
Which is a bit of work to use every time.
Question
I'm looking for a way to declare a list of words to use a specific font within the text.
I know that I can use the listings package and define morekeywords which will be highlighted within the listings-environment but I need it in the text.
I thought of something like this:
\defineList{\fontfamily{cmtt}}{
SOME-KEY-WORD-1,
SOME-Key-word-2,
...
}
EDIT
I forgot to mention that I already tried something like:
\def\somekeyword{\fontfamily{cmtt}\selectfont some\_key\_word\normalfont}
which is a little bit better then the first attempt but I still need to use \somekeyword in the text.
EDIT 2
I came upon a workaround:
\newcommand{\cmtt}[1]{{\fontfamily{cmtt}\selectfont #1\normalfont}}
It's a little better then EDIT but still not the perfect solution.
Substitution every time a word occurs, without providing any clues to TeX, might be difficult and is beyond my skills (though I'd be interested to see someone come up with a solution).
But why not simply create a macro for each of those words?
\newcommand\somekeyword{\fontfamily{cmtt}\selectfont SOME-KEY-WORD}
Use like this:
Hello, \somekeyword{} is the magic word!
The trailing {} are unfortunately necessary to prevent eating the subsequent whitespace; even the built-in \LaTeX command requires them.
If you have very many of these words and are worried about maintainability, you can even create a macro to create the macros:
\newcommand\declareword[2][]{%
\expandafter\newcommand%
\csname\if\relax#1\relax#2\else#1\fi\endcsname%
{{\fontfamily{cmtt}\selectfont #2}}%
}
\declareword{oneword} % defines \oneword
\declareword{otherword} % defines \otherword
\declareword[urlspy]{urls.py} % defines \urlspy
...
The optional argument indicates the name of the command, in case the word itself contains characters like . which cannot be used in the name of a command.
I have this line of code before I create my entity manager:
breeze.NamingConvention.camelCase.setAsDefault();
and this query:
var query = entityQuery.from('vehicle')
.expand("engine, driveType")
.select("engine.friendlyEngineName, driveType.friendlyDrivetrain")
The data comes back like so:
driveType_FriendlyDriveTrain = "Rear Wheel"
engine_FriendlyEngineName = "6.2L V8"
Why are "FriendlyDriveTrain" and "FriendlyEngineName" PascalCase? This seems clearly wrong since I set camelCase before I created the EntityManager and the query. How do I make it so that the parts after the '_' are camelCase as well?
note: I made sure to remove any web api json formatting configurations so that breeze is the only one managing the translation.
edit: The weird thing is that this same query returns properties that are camelCase after the '_' when it hits the cache. So same query, two different results.
Please review the documentation on NamingConvention. If that doesn't clear it up, you can come back and ask a more specific question. Thanks.
Edit 2 Sept 2014 (morning)
Please also explain what you think Breeze should be doing with the "_" character. The Breeze convention treats it like any other identifier character (e.g., a-z,A-Z,0-9) and does nothing with it. It seems you want your convention to skip over leading underscores and lower the case of the first char thereafter if it is alpha. I think you also want to drop the underscores ... but I'm not sure.
That's cool. You can write your own NamingConvention that does what you want. And you can make it the default too. In fact, the noUnderscoreConvention shown on the NamingConvention documentation page is more than half way home for you.
I will say you threw me for a loop with your mix of periods and underscores in the select statement and returned data. I have no idea how you got the select to work or got that kind of result.
Edit 2 Sept 2014 (afternoon)
Ok ... I overlooked the fact that you are doing a projection!
The projection flattens dotted property path values (whether ComplexType or EntityType navigations). It creates projected property names for these "flattened properties" by using "_" as the separator character. Yes, it applies the applicable MetadataStore's naming convention to those "_" separated names and, yes, the Breeze camelCase convention doesn't do anything special with the underscore. So you get back flattened projection property names such as "engine_FriendlyEngineName".
You can call this a bug if you like. I don't. I don't because (a) it seems to me a matter of opinion as to what a camelCase convention should do in this situation; (b) it's been this way forever; and (c) I don't think it is important enough to risk breaking existing applications that might rely on the current behavior ... not when your remedy is so simple.
And that remedy is to write your own camelCase convention that handles these projected property names differently.
Please include it here when you write it so that others who share your perspective may benefit from it.
I'm not sure what you mean when you write: "this same query returns properties that are camelCase after the '_' when it hits the cache". What query is that? Not the one you wrote here.
Projection results don't "hit the cache" ... unless the projected property value is itself an entity ... and that is NOT the case here. What do you mean by "this same query". I await your response.
A coworker is running JSLint on our code and fixing the issues that come up. One change he made was to go from this:
document.getElementById(control["value1"]);
to this:
document.getElementById(control.value1);
Is it JSLint's preference to use the dot notation over array brackets? My understanding from here is that the brackets are a bit more flexible, and I wondered what the best practices from the field were.
Best practice is to use . notation unless you actually need to pass a variable.
This looks more normal, and also allows the JITter to do more intelligent things.
I'm working in a ruby app in which symbols are used in various places where one would usually use strings or enums in other languages (to specify configurations mostly).
So my question is, why should I not add a to_str method to symbol?
It seems seems sensible, as it allows implicit conversion between symbol and string. So I can do stuff like this without having to worry about calling :symbol.to_s:
File.join(:something, "something_else") # => "something/something_else"
The negative is the same as the positive, it implicitly converts symbols to strings, which can be REALLY confusing if it causes an obscure bug, but given how symbols are generally used, I'm not sure if this is a valid concern.
Any thoughts?
when an object does respond_to? :to_str, you expect him to really act like a String. This means it should implement all of String's methods, so you could potentially break some code relying on this.
to_s means that you get a string representation of your object, that's why so many objects implement it - but the string you get is far from being 'semantically' equivalent to your object ( an_hash.to_s is far from being a Hash ). :symbol.to_str's absence reflects this : a symbol is NOT and MUST NOT be confused with a string in Ruby, because they serve totally different purposes.
You wouldn't think about adding to_str to an Int, right ? Yet an Int has a lot of common with a symbol : each one of them is unique. When you have a symbol, you expect it to be unique and immutable as well.
You don't have to implicitly convert it right? Because doing something like this will automatically coerce it to a string.
"#{:something}/something_else" # "something/something_else"
The negative is what you say--at one point, anyway, some core Ruby had different behavior based on symbol/string. I don't know if that's still the case. The threat alone makes me a little twitchy, but I don't have a solid technical reason at this point. I guess the thought of making a symbol more string-like just makes me nervous.
I've recently been receiving a lot of first name only entries in a form. While maybe I should have had 2 separate first and last name fields this always seemed to me a bit much. But I would like to try and get a full name which basically can only be determined by having at least one space.
I came up with this, but I'm wondering if someone has a better and possibly simpler solution?
/([a-zA-ZàáâäãåèéêëìíîïòóôöõøùúûüÿýñçčšžÀÁÂÄÃÅÈÉÊËÌÍÎÏÒÓÔÖÕØÙÚÛÜŸÝÑßÇŒÆČŠŽ∂ð,.'-]{2,}) ([a-zA-ZàáâäãåèéêëìíîïòóôöõøùúûüÿýñçčšžÀÁÂÄÃÅÈÉÊËÌÍÎÏÒÓÔÖÕØÙÚÛÜŸÝÑßÇŒÆČŠŽ∂ð,.'-]{2,})/
This is basically this /([a-zA-Z,.'-]) ([a-zA-Z,.'-])/ plus unicode support.
I'd first make sure that you really do need people to give you a last name. Is that a genuine requirement? If not, I'd skip it because it adds unnecessary complication and barriers to entry. If it really IS a requirement, it probably makes sense to have separate first and last name fields in your UI so that it's explicit.
The fact that you didn't do that to begin with suggests that you might not really need the last name as much as you think you do.
To answer your original question, this expression might give you what you're looking for without the guesswork:
/[\w]+([\s]+[\w]+){1}+/
It checks that the string contains at least 2 words separated by whitespace. Like Tim Pietzcker pointed out, validating the words themselves is prone to error.
In Ruby 1.9, you have access to Unicode properties (\p{L} is a Unicode letter). But trying to validate a name in any way (regex or not) is prone to failure because names are not what you think they are.
Your theory that "if there's a space, there must be a last name there" is incorrect, too - think of first and middle names...