<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 30, 2014 at 12:46 PM, Evgeny Sazhin <span dir="ltr"><<a href="mailto:eugene@sazhin.us" target="_blank">eugene@sazhin.us</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Thu, Jan 30, 2014 at 11:59 AM, Donald Stufft <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br>
><br>
> On Jan 30, 2014, at 11:33 AM, Evgeny Sazhin <<a href="mailto:eugene@sazhin.us">eugene@sazhin.us</a>> wrote:<br>
><br>
>> On Thu, Jan 30, 2014 at 3:09 AM, Paul Moore <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br>
>>> On 30 January 2014 05:33, Evgeny Sazhin <<a href="mailto:eugene@sazhin.us">eugene@sazhin.us</a>> wrote:<br>
>>>>> Eh, I think both 1 and 3 are things that are possibly reasonable to happen and<br>
>>>>> they are both things that I've contemplated as things to bring forward in<br>
>>>>> using xz as an alternative compression format. Even if #1 would need a major<br>
>>>>> revision of Wheel to happen adding official "support" for zip import means that<br>
>>>>> the change would have to be weighed against also breaking that backwards<br>
>>>>> compatibility.<br>
>>>><br>
>>>><br>
>>>> Eh, please don't break it!! Improve! Keep the ability to add wheels to python path.<br>
>>>> I don't care how, zip import, non-zip import, whatever - allow for jar-like behavior - people will thank you if it will work properly !;)<br>
>>>> I know, i'm probably alone in the desert...l;)<br>
>>><br>
>>> This is the biggest concern I see with "promoting" wheels being<br>
>>> directly importable via zipimport (I say "promoting" and not<br>
>>> "specifying" deliberately, but I don't want to get back into the<br>
>>> process debate).<br>
>>><br>
>>> People like Evgeny (no offense intended here, but your post is a good<br>
>>> example to use) coming from a Java background will see importable<br>
>>> wheels and *think* that they are similar in purpose to jars.<br>
>><br>
>> No offense taken - i'm happy to be a use case to add some perspective;))<br>
>><br>
>>> This is<br>
>>> not, and never will be, true. Python is not Java, deployment by<br>
>>> putting jar-like files on sys.path is not an advisable workflow for<br>
>>> Python - no matter what parallels with Java might make it look<br>
>>> attractive.<br>
>><br>
>> For pure python wheels - you're right - very attractive! And while i<br>
>> hear you guys saying it is not advisable to use wheels in sys.path i'm<br>
>> still far from seeing good reasoning. Please, correct me, but so far i<br>
>> saw 2:<br>
>><br>
>> 1. It is impossible to load C extensions<br>
>> 2. Error handling is bad<br>
>><br>
>> None of these reasons seems to be good enough to lead to a conclusion<br>
>> that wheel used as jar-like thing is not needed. Here is how i see it<br>
>> (again probably to my lack of knowledge):<br>
>><br>
>> 1. Yes there is a group of "elite" interesting projects that are using<br>
>> C extensions together with python code. What i don't understand is why<br>
>> are wheels supposed to be tailored to the needs of the hybrid projects<br>
>> instead of making pure python first priority? There is big crowd using<br>
>> C extensions, but how much bigger is the crowd who doesn't? Why law<br>
>> abiding pure python developer should jump through the hoops?<br>
><br>
> Because C extensions are not "elite", they are pretty common. It's somewhat<br>
> rare in my experience to see a non trivial project that doesn't have a C<br>
> extension somewhere in it.<br>
<br>
</div></div>Isn't this a self contradictory statement? C extensions are quite<br>
common for non-trivial project. non-trivial is not common.<br>
Doesn't it mean that C extensions are rarely used for common trivial<br>
stuff? You also implying that there were non-trivial projects that<br>
didn't need C extensions. Or are you trying to make an argument that<br>
the overall majority of python projects have C extensions?</blockquote><div><br></div><div>He's trying to argue that enough projects use C extensions that to have special support for projects that don't use them is supporting a special case. The Zen of Python says "<span style="color:rgb(0,0,0);line-height:17.8231201171875px">Special cases aren't special enough to break the rules" and explicitly having wheels support direct execution only when they contain pure Python is supporting a special case. Obviously you can argue over at what point something stops being a "special case", but considering venvs isolate code well and are the officially supported way to isolate code then that makes stuff that goes passed what venv can do a special case.</span></div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> Is python<br>
such a bad language it cannot deal with simple stuff without C being<br>
involved?<br></blockquote><div><br></div><div>The use of a C extension does not necessarily mean a shortcoming of Python. People can write performance-critical code in C so as to get that last bit of speed in heavily executed code in a tight loop, etc. It has nothing to do with Python not being able to handle something and more that C code can simply be faster when coded correctly; it's a feature and not a band-aid.</div>
<div><br></div><div>-Brett</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
<br>
><br>
>><br>
>> 2. IF we are talking about error handling it seems that people<br>
>> generally do not consider jar-like behavior to be bad for pure python<br>
>> modules - It's just doesn't work very well (yet?). Is there really a<br>
>> problem with error handling for pure python? What if the error<br>
>> handling is improved? Is it still going to be bad? Why?<br>
><br>
> i consider the fact that they'll only work in a subset of situations bad,<br>
> because it's non obvious without digging through the code if any<br>
> particular project will support working from a place other than<br>
> a traditional install.<br>
<br>
</div>The necessity to dig through the code to understand if the project is<br>
runnable from zip is a responsibility of project provider - i.e. poor<br>
documentation.<br>
If the project is designed to be run that way the doc should say so.<br>
<div class="im"><br>
<br>
>This isn't a new feature, Eggs have had this for<br>
> a long time and when confronted with bugs caused by zipped Eggs<br>
> the common solution is simply adding zip_safe=False to their project<br>
> which disables zipped eggs for that project.<br>
><br>
> The name for the kind of feature this is, is an "attractive nuisance". They<br>
> look like something that might work, especially to people coming to<br>
> Python from other languages such as Java, but if actually use the<br>
> feature in a non trivial fashion you're going to end up with more<br>
> problems then you've solved when random projects simply don't work<br>
> and the likelihood that their authors have no desire to support running<br>
> through a zipped file even if they *could* make it possible.<br>
<br>
</div>OK, you're saying " if actually use the feature in a non trivial fashion"<br>
But was is non-trivial in putting pure python wheel in sys.path?<br>
Non-trivial would probably<br>
mean trying to load c extension from it, but that's obviously not supported,<br>
so i wouldn't even try.<br>
<br>
<br>
Thanks,<br>
Eugene<br>
<div class=""><div class="h5">_______________________________________________<br>
Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</div></div></blockquote></div><br></div></div>