<div dir="ltr">> <span style="font-family:arial,sans-serif;font-size:13px">So you would have to use some editor with up-to-date support and do it</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">at run-time.  No web viewers.  No distro-installed editors.  This has</span><br style="font-family:arial,sans-serif;font-size:13px">

<span style="font-family:arial,sans-serif;font-size:13px">a particularly smell to it.</span><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">Grep is hardly an editor with up to date support! It'd just be like looking up a function you don't know. Either it's in the docs, or if not, you start grepping. Literally, it will be exactly like looking up a function! It's not like grepping for "@str_prefix\ndef regex" is any harder than grepping for "def regex"!</span></div>

<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><font face="arial, sans-serif">> </font><span style="font-family:arial,sans-serif;font-size:13px">Then put them in a class with the related methods.  However, my whole</span></div>

<span style="font-family:arial,sans-serif;font-size:13px">moving-things-around recommendation is orthogonal to this proposal.</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">Handling a prefix during a function call would be equivalent (or even</span><br style="font-family:arial,sans-serif;font-size:13px">

<span style="font-family:arial,sans-serif;font-size:13px">less performant) to explicitly calling the handler.</span><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><font face="arial, sans-serif">The idea was to handle the prefix at either import or compile time (i'm not actually sure of the distinction, although i'm sure there is one), so it would be fully inlined by the time the code starts executed (over and over). I don't think "big class full of related static methods only called once" is a very good way of organizing code, and the reason people do (and they do do it!) it for use cases like this is because they have to, not because they like to.</font></div>

<div style><font face="arial, sans-serif"><br></font></div><div style><font face="arial, sans-serif">> </font><span style="font-family:arial,sans-serif;font-size:13px">p.s. Do you think this feature would ever be used in the standard</span></div>

<span style="font-family:arial,sans-serif;font-size:13px">library if it made it into the language?</span><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">Maybe? I could imagine the regex module using it right away for a very nice syntax for:</span></div>

<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">regex"<my-big-regex>".match(...)</span></div><div style>

<span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">While simultaneously getting rid of the behaviourally unspecified global-compiled-regex-cache (what does "<a href="http://docs.python.org/3.3/library/re.html?highlight=re.sub#re.compile">a few regular expressions at a time</a>" mean anyway?) in favor of per-regex-literal interning of compiled regexes, which is what the global-compiled-regex-cache is trying to approximate anyway. </span><span style="font-family:arial,sans-serif;font-size:13px">The sqlite3 (or sqlite4 or sqlite10) module could eventually use this to pre-parse SQL literal queries, as well as the xml libraries for pre-parsing XML blobstrings. If any of the parser-combinator libraries like Parsimonious end up in the std lib, they could definitely use it too.</span></div>

<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">Anyway, I don't expect everyone to get up and agree with me all of a sudden, or to have it used in the std lib tomorrow, so it's OK if you disagree with my judgement or your experience tells you it's a bad idea. I just thought it's worth a substantive debate because I think it's a neat idea that's started appearing in other places, and the OP brought it up, so there's some indication it's not just me being crazy. I've made all the points I want to make, so I should probably stop talking now.</span></div>

<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">-Haoyi</span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">

On Thu, May 30, 2013 at 4:00 PM, Eric Snow <span dir="ltr"><<a href="mailto:ericsnowcurrently@gmail.com" target="_blank">ericsnowcurrently@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On Thu, May 30, 2013 at 4:42 AM, Haoyi Li <<a href="mailto:haoyi.sg@gmail.com">haoyi.sg@gmail.com</a>> wrote:<br>
>> The language needs to fit in our brains and you could argue<br>
> that we've already pushed past that threshold<br>
><br>
> I would argue that "prefix just calls the registered function at import<br>
> time" fits with my brain better then "20 special cases in the lexer which<br>
> result in magic things happening", but maybe that's just me.<br>
<br>
</div>The existing prefixes are not going away, but they are easy to look up<br>
in the docs.  So that brain-space is not going way.  Additionally,<br>
under this proposal those prefixes could change meaning at run-time.<br>
Furthermore, you could encounter prefixes that are not in the docs and<br>
you would have to know how to figure out what they are supposed to do.<br>
 Right now there is zero ambiguity about what the prefixes do.<br>
<br>
So this proposal would simply be adding one more thing that has to fit<br>
inside your brain without adding any power to the language.  On top of<br>
that I'm not seeing why this would be very widely used meaning people<br>
would probably not recognize what's going on at first.  This is rough<br>
on the non-experts, and adds more complexity to the language where we<br>
already have a perfectly good way of doing the same thing (explicit<br>
function calls).<br>
<div class="im"><br>
><br>
>> One concern I'd have<br>
> is in how you would look up what some arbitrary prefix is supposed to<br>
> do<br>
><br>
> In theory PyCharm/Vim/Emacs would be able to just jump to the definition of<br>
> the prefix, instantly giving you the docstring along with the source code of<br>
> what it does, so I don't think this is a real problem. Tool support will<br>
> catch up, as always, and you could always grep "@str_prefix\ndef blah" or<br>
> something similar.<br>
<br>
</div>So you would have to use some editor with up-to-date support and do it<br>
at run-time.  No web viewers.  No distro-installed editors.  This has<br>
a particularly smell to it.<br>
<div class="im"><br>
><br>
>> Furthermore, it sounds like the intent is to apply the prefix at<br>
> run-time.<br>
><br>
> Is there any other time in Python? There's only import-time and<br>
> execution-time to choose from.<br>
<br>
</div>1. compile-time (during import with no up-to-date .pyc file)<br>
2. run-time<br>
2a. import time (execution of the module)<br>
2b. call-time (execution of a function body)<br>
<br>
.pyc files allow us to skip this part after the first time.  Currently<br>
string prefixes are handled at compile time.  This proposal moves it<br>
to run-time.  Furthermore, only the raw string literals would still<br>
actually be literals and able to be interned/compiled away/stored in a<br>
functions constants.  But now there would be extra byte codes used in<br>
the compiled code to process the raw literals.  All for the sake of<br>
hypothetical use cases that can already be handled by explicit<br>
function calls.<br>
<div class="im"><br>
><br>
>> That means that the function that gets applied depends on<br>
> what's in some registry at a given moment.  So source with these<br>
> custom string prefixes will be even more ambiguous when read.<br>
><br>
> I don't think the second line follows from the first. You could say the same<br>
> of PEP302 import hooks, which overload a fundamental operation (import xxx)<br>
> to do whatever the hell you want, depending on what's in your sys.meta_path<br>
> at any given moment. Heck, you could say the same of any function call<br>
> my_func(...), that it depends on what my_func has been defined as at a given<br>
> moment! Remember functions can be (and often are!) rebound multiple times,<br>
> but people seem to get by just fine.<br>
<br>
</div>Consider that the import system is a giant black box for most people<br>
and even gives the experts fits.  Comparing this proposal to it really<br>
says something.  Furthermore, existing dynamic-language-induced<br>
challenges do not justify adding more.<br>
<div class="im"><br>
><br>
>> In that case, why not just call the<br>
> function at the module scope, bind the result to a name there, and use<br>
> that name wherever you like.  It's effectively a constant, right?<br>
><br>
> The main reason I'd give is that moving a whole bunch of things into module<br>
> scope spaghettifies your program. If I'm making a bunch of SQL queries in a<br>
> bunch of functions, I expect the SQL to be in the functions where I'm using<br>
> them (nobody else cares about them, right?) rather than at module scope.<br>
> Moving stuff to module scope for performance adds another layer of<br>
> unnecessary indirection when i look at my_function and wonder what<br>
> my_function_sql_query and my_function_xml_template is meant to do, for every<br>
> single function.<br>
<br>
</div>Then put them in a class with the related methods.  However, my whole<br>
moving-things-around recommendation is orthogonal to this proposal.<br>
Handling a prefix during a function call would be equivalent (or even<br>
less performant) to explicitly calling the handler.<br>
<br>
Bottom line: I'm still not seeing the utility of this feature over<br>
plain function calls.<br>
<span class="HOEnZb"><font color="#888888"><br>
-eric<br>
</font></span><br>
p.s. Do you think this feature would ever be used in the standard<br>
library if it made it into the language?<br>
</blockquote></div><br></div>