[Python-Dev] Need help in OCR implementation with Python3.5.1 or pyCharm Community edition
> Dear All,
> I am new to python and very much excited to learn this technology.
> I have done setup of python 3.5.1 with PyCharm community edition on windows
> 7(64bit service pack 1).
> I am trying to execute some piece of code but it fails . Requesting you to
> please help.
>
> My Piece of code is
> import pytesseract
> from PIL import Image
> from PIL import ImageFilter
> import os
> print (os.getcwd())
> url="Polish.png"
> def process_image(url):
> image = _get_image(url)
> image = image.filter(ImageFilter.SHARPEN)
> #image = image.convert('1')
> print (pytesseract.image_to_string(image))
>
> def _get_image(url):
> return Image.open(url)
>
> process_image(url)
>
> Error which I am getting ,
> C:\Users\Administrator\AppData\Local\Programs\Python\Python35-32\python.exe
> C:/Temp/Opt/src/ocr.py
> C:\Temp\Opt\src
> in subprocess
> None
> 0
> None
> None
>
> Traceback (most recent call last):
> File "C:/Temp/Opt/src/ocr.py", line 17, in
> process_image(url)
> File "C:/Temp/Opt/src/ocr.py", line 12, in process_image
> print (pytesseract.image_to_string(image))
> File
> "C:\Users\Administrator\AppData\Roaming\Python\Python35\site-packages\pytesseract\pytesseract.py",
> line 161, in image_to_string
> config=config)
> File
> "C:\Users\Administrator\AppData\Roaming\Python\Python35\site-packages\pytesseract\pytesseract.py",
> line 94, in run_tesseract
> stderr=subprocess.PIPE)
> File
> "C:\Users\Administrator\AppData\Local\Programs\Python\Python35-32\lib\subprocess.py",
> line 950, in __init__
> restore_signals, start_new_session)
> File
> "C:\Users\Administrator\AppData\Local\Programs\Python\Python35-32\lib\subprocess.py",
> line 1226, in _execute_child
> startupinfo)
> FileNotFoundError: [WinError 2] The system cannot find the file specified
>
> Process finished with exit code 1
>
> Thanks and Regards
> Deepak Srivastava
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Need help in OCR implementation with Python3.5.1 or pyCharm Community edition
On Thu, May 5, 2016 at 3:24 AM, Deepak Srivastava
wrote:
>
> Dear All,
>
> I am new to python and very much excited to learn this technology.
>
> I have done setup of python 3.5.1 with PyCharm community edition on
> windows 7(64bit service pack 1).
>
> I am trying to execute some piece of code but it fails . Requesting you to
> please help.
>
>
>
> My Piece of code is
>
> *import *pytesseract
> *from *PIL *import *Image
> *from *PIL *import *ImageFilter
> *import *os
> print (os.getcwd())
> url=
> *"Polish.png"**def *process_image(*url*):
> image = _get_image(*url*)
> image = image.filter(ImageFilter.SHARPEN)
> #image = image.convert('1')
> print (pytesseract.image_to_string(image))
>
> *def *_get_image(*url*):
> *return *Image.open(*url*)
>
> process_image(url)
>
>
>
> Error which I am getting ,
>
> *C:\Users\Administrator\AppData\Local\Programs\Python\Python35-32\python.exe
> C:/Temp/Opt/src/ocr.py*
>
> *C:\Temp\Opt\src*
>
> *in subprocess*
>
> *None*
>
> *0*
>
> *None*
>
> *None*
>
> **
>
> *Traceback (most recent call last):*
>
> * File "C:/Temp/Opt/src/ocr.py", line 17, in *
>
> *process_image(url)*
>
> * File "C:/Temp/Opt/src/ocr.py", line 12, in process_image*
>
> *print (pytesseract.image_to_string(image))*
>
> * File
> "C:\Users\Administrator\AppData\Roaming\Python\Python35\site-packages\pytesseract\pytesseract.py",
> line 161, in image_to_string*
>
> *config=config)*
>
> * File
> "C:\Users\Administrator\AppData\Roaming\Python\Python35\site-packages\pytesseract\pytesseract.py",
> line 94, in run_tesseract*
>
> *stderr=subprocess.PIPE)*
>
> * File
> "C:\Users\Administrator\AppData\Local\Programs\Python\Python35-32\lib\subprocess.py",
> line 950, in __init__*
>
> *restore_signals, start_new_session)*
>
> * File
> "C:\Users\Administrator\AppData\Local\Programs\Python\Python35-32\lib\subprocess.py",
> line 1226, in _execute_child*
>
> *startupinfo)*
>
> *FileNotFoundError: [WinError 2] The system cannot find the file specified*
>
>
>
> *Process finished with exit code 1*
>
>
>
> Thanks and Regards
>
> Deepak Srivastava
>
>
>
>
Questions like this are better suited for python-list. Regardless, you need
to install Tesseract first:
https://github.com/tesseract-ocr/tesseract/wiki
That should fix the error.
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>
>
--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Need help in OCR implementation with Python3.5.1 or pyCharm Community edition
On 2016-05-05 16:26, Ryan Gonzalez wrote: On Thu, May 5, 2016 at 3:24 AM, Deepak Srivastava mailto:[email protected]>> wrote: Dear All, I am new to python and very much excited to learn this technology. I have done setup of python 3.5.1 with PyCharm community edition on windows 7(64bit service pack 1). I am trying to execute some piece of code but it fails . Requesting you to please help. My Piece of code is /import /pytesseract /from /PIL /import /Image /from /PIL /import /ImageFilter /import /os print (os.getcwd()) url=*"Polish.png" */def /process_image(/url/): image = _get_image(/url/) image = image.filter(ImageFilter.SHARPEN) #image = image.convert('1') print (pytesseract.image_to_string(image)) /def /_get_image(/url/): /return /Image.open(/url/) process_image(url) Error which I am getting , *C:\Users\Administrator\AppData\Local\Programs\Python\Python35-32\python.exe C:/Temp/Opt/src/ocr.py* *C:\Temp\Opt\src* *in subprocess* *None* *0* *None* *None* ** *Traceback (most recent call last):* * File "C:/Temp/Opt/src/ocr.py", line 17, in * *process_image(url)* * File "C:/Temp/Opt/src/ocr.py", line 12, in process_image* *print (pytesseract.image_to_string(image))* * File "C:\Users\Administrator\AppData\Roaming\Python\Python35\site-packages\pytesseract\pytesseract.py", line 161, in image_to_string* *config=config)* * File "C:\Users\Administrator\AppData\Roaming\Python\Python35\site-packages\pytesseract\pytesseract.py", line 94, in run_tesseract* *stderr=subprocess.PIPE)* * File "C:\Users\Administrator\AppData\Local\Programs\Python\Python35-32\lib\subprocess.py", line 950, in __init__* *restore_signals, start_new_session)* * File "C:\Users\Administrator\AppData\Local\Programs\Python\Python35-32\lib\subprocess.py", line 1226, in _execute_child* *startupinfo)* *FileNotFoundError: [WinError 2] The system cannot find the file specified* ** *Process finished with exit code 1* Thanks and Regards Deepak Srivastava Questions like this are better suited for python-list. Regardless, you need to install Tesseract first: https://github.com/tesseract-ocr/tesseract/wiki That should fix the error. It looks to me that it's the url="Polish.png" that's the real cause of the problem. It's not clear where the file "Polish.png" is actually stored. It would be better to use a full file path. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Need help in OCR implementation with Python3.5.1 or pyCharm Community edition
On Thu, May 05, 2016 at 05:23:02PM +0100, MRAB wrote: > On 2016-05-05 16:26, Ryan Gonzalez wrote: > >On Thu, May 5, 2016 at 3:24 AM, Deepak Srivastava [ ... about three or four pages of quoting ... ] > >Questions like this are better suited for python-list. [...] > It looks to me that it's the url="Polish.png" [...] Guys, it's bad enough that you're engaging in problem-solving mode for an off-topic question, but could you at least trim your replies first? There's no need to quote the entire body of the OP's post (three or four pages worth) only to add a two or three line comment to the end. Have pity on your readers and use the delete key on some of the unnecessary text, please? -- Steve ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units
Here is something I wrote because I was also unsatisfied with byteplay's API: https://github.com/zachariahreed/byteasm. Maybe it's useful in a discussion of "minimum viable" api for bytecode manipulation. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Need help in OCR implementation with Python3.5.1 or pyCharm Community edition
Well, the stack trace was pointing to the line that called Tesseract, so I figured that was the problem. -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/ On May 5, 2016 11:24 AM, "MRAB" wrote: > > It looks to me that it's the url="Polish.png" that's the real cause of the problem. It's not clear where the file "Polish.png" is actually stored. It would be better to use a full file path. > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Yearly PyPI breakage
Nick Coghlan gmail.com> writes: > I know you're not happy with myself and the other distutils-sig folks > regarding the decision to deprecate and remove automatic link > spidering, More accurately: Not happy with the removal of the checksummed "explicit" mode. What I would have preferred is a FreeBSD-like ports system. FreeBSD has been used in huge and secure installations, so the I don't buy the reliability and security arguments that are used in favor of centralization. But centralization seems to be a goal in and of itself these days (and that isn't limited to Python). > nor with the PSF regarding the current Terms of Service > around uploads to PyPI, but that doesn't make it OK to start off-topic > threads on python-dev just because you're a CPython core developer in > addition to being a PyPI user. Alexander thought otherwise: https://mail.python.org/pipermail/python-dev/2015-October/141840.html "Given that ensurepip is part of stdlib, I am not sure this is an accurate statement. Even if it was, did you make any effort to discuss the proposal outside of a small group subscribed to distutils ML?" I completely agree with that. Fredrik Lundh is also affected (and might not have received any mail, same as me): https://pypi.python.org/pypi/PIL > It *definitely* doesn't make it OK to accuse people of conspiring > against you when they answer your question in good faith, just because > their answer is the official distutils-sig/PyPA one (which was > approved through the PEP process in PEP 470). I'm not sure what you are referring to. Donald posted a link to PEP 470, in my response to Nathaniel I acknowledged this. In my exchange with Łukasz we both came to the conclusion (I think) that further discussion would be futile. IMO all responses from Brett, Donald, Nathaniel and Łukasz were reasonable and I haven't accused them of conspiring in the slightest. I see that the PEP was accepted by Paul Moore. I couldn't even dream of accusing Paul Moore of any kind of conspiracy. He's one of the most reasonable (and *genuinely* polite) people on these mailing lists. Or are you referring to a super-condescending flame bait where someone cloned a private website, assumed general ignorance and then proceeded to offer a hostile fork to anyone who would be interested? Well, I accepted the flame bait. > - writing to psf-legal to let them know whether or not Van Lindberg's > draft updates to the Terms of Service would be sufficient to make you > comfortable with uploading cdecimal to PyPI in addition to bundling it > with the standard library under your existing Contributor Licensing > Agreement: https://bitbucket.org/vanl/pypi/src/default/templates Okay, so there was recent progress here. This is actual news to me. Do you remember what kind of derision I went through for just suggesting something like that a couple of years ago? Yes, you supported me, but what about the others? Or that Van Lindberg was in the merry group of Twitter heroes who were gloating about the fact that (in their opinion) I could not do anything about the first hostile fork? Technically, he didn't gloat, but suddenly legal advice was apparently readily available. https://pypi.python.org/pypi/m3-cdecimal I can assure you that CoCs or "diversity statements" won't help you at all. Stefan Krah ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Yearly PyPI breakage
On 05/05/2016 23:22, Stefan Krah wrote Fredrik Lundh is also affected (and might not have received any mail, same as me): https://pypi.python.org/pypi/PIL He might be, but clearly the Python community as a whole is not impacted. From what I see the latest version of PIL that is available is 1.1.6, which requires Python 1.5.2 or higher, and has the following stats:- 0 downloads in the last day 0 downloads in the last week 0 downloads in the last month I wish I could vent my feelings regarding your comments earlier in this thread but I won't, as apparently core developers can say what they like with no comeback, whereas plebs like me can and will get hammered by the Python community, despite having explained that a combination of anxiety, depression, chronic fatigue syndrome, insomnia, autism and diplopia makes life rather difficult. Unless of course you have similar problems, in which case please say so. The rest of the community might not understand, I certainly will. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Yearly PyPI breakage
> > Fredrik Lundh is also affected (and might not have received any mail, >> same as me): >> >> https://pypi.python.org/pypi/PIL >> >> > He might be, but clearly the Python community as a whole is not impacted. > From what I see the latest version of PIL that is available is 1.1.6, which > requires Python 1.5.2 or higher, Indeed -- Fredrik never made any effort to support pypi, pip, etc. -- that's why the Pillow fork was started in the first place. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Yearly PyPI breakage
On May 05, 2016, at 11:58 PM, Mark Lawrence via Python-Dev wrote: >On 05/05/2016 23:22, Stefan Krah wrote >> >> Fredrik Lundh is also affected (and might not have received any mail, >> same as me): >> >> https://pypi.python.org/pypi/PIL Maybe, but then there's the friendly fork: https://pypi.python.org/pypi/Pillow/3.2.0 -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Yearly PyPI breakage
> On May 5, 2016, at 6:22 PM, Stefan Krah wrote: > > Nick Coghlan gmail.com> writes: >> I know you're not happy with myself and the other distutils-sig folks >> regarding the decision to deprecate and remove automatic link >> spidering, > > More accurately: Not happy with the removal of the checksummed "explicit" > mode. What I would have preferred is a FreeBSD-like ports system. FreeBSD > has been used in huge and secure installations, so the I don't buy the > reliability and security arguments that are used in favor of centralization. > But centralization seems to be a goal in and of itself these days (and > that isn't limited to Python). Let me say outright that there is nothing wrong with a well designed, ports like system. However, PyPI was not that and the vast bulk of packages were not using it in that fashion. At the time of PEP 470 being written a mere 59 out of 65,232 (at the time) projects were utilizing the feature that allowed people to safely do a ports like system. That's roughly 0.09% of all of the projects on PyPI which meant those projects were in a very serious minority. Thus it is only natural that the expectations end users had when installing software was that it was coming from PyPI, not from some external host and they made decisions based around those expectations and when those expectations were violated they came to the people operating PyPI and developing pip and were at best very confused, and at worst irate at *us*. It's also true that there are benefits and cons to both a repository centric approach and a ports style approach, however since we were attempting to do both in one repository it typically meant that we got all of the cons of both systems, but we couldn't ever take advantage of any of the unique benefits of either system since it would only apply to some fraction of the projects. This meant that improvements that would help people installing 99.11% of projects would end up getting blocked by 0.09% of projects. At the end of the day, attempting to both things in one repository just wasn't working out very well in the general case, so we needed (IMO) to pick one way and stop supporting the other way. I personally think it's a pretty obvious choice to go the way that we did, given that the overwhelming majority of projects were already being used that way. That being said, I don't think the characterization of "centralizing" is really accurate here. People are still free to host their projects wherever they want and pip (and easy_install) can be used to install them. All it requires is telling pip where it needs to look in addition to the default location (PyPI), which can be configured via the CLI, environment variables, or a number of configuration files at the system, user, and virtual environment level. You're free to continue providing a page on PyPI to enable discovery of your project and you can include in that page instructions on how to install your project. > > >> nor with the PSF regarding the current Terms of Service >> around uploads to PyPI, but that doesn't make it OK to start off-topic >> threads on python-dev just because you're a CPython core developer in >> addition to being a PyPI user. > > Alexander thought otherwise: > > https://mail.python.org/pipermail/python-dev/2015-October/141840.html > > "Given that ensurepip is part of stdlib, I am not sure this is an accurate > statement. Even if it was, did you make any effort to discuss the proposal > outside of a small group subscribed to distutils ML?" > > I completely agree with that. We've sort of hijacked the PEP process to do something that it wasn't really meant to do. Changes like PEP 470 have nothing to do with what Python itself does and thus it's really outside of the realm of where python-dev really needs a say or notification. In Alexander's example of PEP 495 it was talking about adding a new API to Python itself, thus it makes sense that python-dev should be told about that PEP, and in cases where we needed to change the standard library we've done that discussion on python-dev (such as with PEP 453). The python-dev list is not the list to notify people of changes to things in all corners of the Python ecosystem. If people want to get involved or keep abreast of the changes in the external projects of PyPI, pip, setuptools, etc then they should subscribe to the places that those changes get discussed-- which is distutils-sig. Packaging already has enough problems with getting bogged down in "why wasn't I consulted" and bikeshedding, I don't think that inviting folks (and nothing against python-dev here) a chance to try and re-legislate an agreed upon change after the fact is going to provide much in the way of benefits and will instead just contribute further to stymying efforts to move packaging forward. If it was decided that we really need all PEPs announced on python-dev and python-dev given a chance to weigh in, I would advocate for packaging to stop using the P
Re: [Python-Dev] Yearly PyPI breakage
Chris Barker noaa.gov> writes: > Indeed -- Fredrik never made any effort to support pypi, pip, etc. -- that's why the Pillow fork was started in the first place. Maybe, but he created PIL, so thank you, Fredrik! Stefan Krah ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Yearly PyPI breakage
On 06/05/2016 00:06, Barry Warsaw wrote: On May 05, 2016, at 11:58 PM, Mark Lawrence via Python-Dev wrote: On 05/05/2016 23:22, Stefan Krah wrote Fredrik Lundh is also affected (and might not have received any mail, same as me): https://pypi.python.org/pypi/PIL Maybe, but then there's the friendly fork: https://pypi.python.org/pypi/Pillow/3.2.0 -Barry Where is the relevance to my words that you've snipped? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Yearly PyPI breakage
This is mostly just observational, and not meant primarily as criticism of the fabulous work of Donald and others (ignoring pypa, also the prompt, reliable, and skilled support responses common on such places as IRC), however I can't help but notice that PyPI governance seems to come under fire vastly more often than similar and much more popular packaging systems, and some choices that have been made particularly in recent years have caused a noticeable amount of dissent with what might be considered the typical developer. When a contributor to the core language is having repeat issues maintaining some basic element of the function of the packaging system, might it be fair to reflect on how changes to those functions are being managed? There are PEPs covering a great deal of the work done to PyPI recently, but, and I say this as someone who has bumped into friction with the packaging tooling in the relatively recent past, even I despite my motivations to the contrary, I have not read most of them. It seems the current process is observed by few, does not sufficiently address the range of traditional use cases that were possible in the past, and the first the common user learns of a change is when pip (after insisting it must be upgraded) fails to function as it previously did. The usual course then is some complaint, that leads to distutils-sig, which ultimately leads to pointing at some design work that was only observed by perhaps 50 people max that turns out had some edge cases that hurt in a common use case. Is there something to contemplate in here? I dislike posting questions instead of answers, but it seems apparent there is a problem here and it continues to remain unaddressed. David On Tue, May 03, 2016 at 07:06:12PM +, Stefan Krah wrote: > > Hello, > > Could someone enlighten me which hoops I have to jump through > this year in order to keep pip downloads working? > > Collecting cdecimal > Could not find a version that satisfies the requirement cdecimal (from > versions: ) > No matching distribution found for cdecimal > You are using pip version 7.1.2, however version 8.1.1 is available. > You should consider upgrading via the 'pip install --upgrade pip' command. > > > If this continues, I'm going to release a premium version that's > 50% faster and only available from bytereef.org or Anaconda. > > > > Stefan Krah > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/dw%2Bpython-dev%40hmmz.org ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Yearly PyPI breakage
On Thu, 5 May 2016 at 16:54 David Wilson wrote: > This is mostly just observational, and not meant primarily as criticism > of the fabulous work of Donald and others (ignoring pypa, also the > prompt, reliable, and skilled support responses common on such places as > IRC), however I can't help but notice that PyPI governance seems to come > under fire vastly more often than similar and much more popular > packaging systems, and some choices that have been made particularly in > recent years have caused a noticeable amount of dissent with what might > be considered the typical developer. > > When a contributor to the core language is having repeat issues > maintaining some basic element of the function of the packaging system, > might it be fair to reflect on how changes to those functions are being > managed? > > There are PEPs covering a great deal of the work done to PyPI recently, > but, and I say this as someone who has bumped into friction with the > packaging tooling in the relatively recent past, even I despite my > motivations to the contrary, I have not read most of them. It seems the > current process is observed by few, does not sufficiently address the > range of traditional use cases that were possible in the past, and the > first the common user learns of a change is when pip (after insisting it > must be upgraded) fails to function as it previously did. > > The usual course then is some complaint, that leads to distutils-sig, > which ultimately leads to pointing at some design work that was only > observed by perhaps 50 people max that turns out had some edge cases > that hurt in a common use case. > > Is there something to contemplate in here? I dislike posting questions > instead of answers, but it seems apparent there is a problem here and it > continues to remain unaddressed. > This is whole thread is off-topic precisely because all of this is discussed -- in the open -- on distutils-sig and decided there. If people feel changes need to be made like broadcasting to a wider audience when a change occurs, then please bring it up on distutils-sig. But if people choose not to participate then they are implicitly delegating decision powers to those who do participate (which is totally fine and I'm not implying that if people don't participate they are doing something wrong). ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Yearly PyPI breakage
On Thu, 5 May 2016 at 16:00 Mark Lawrence via Python-Dev < [email protected]> wrote: > On 05/05/2016 23:22, Stefan Krah wrote > > > > Fredrik Lundh is also affected (and might not have received any mail, > > same as me): > > > > https://pypi.python.org/pypi/PIL > > > > He might be, but clearly the Python community as a whole is not > impacted. From what I see the latest version of PIL that is available > is 1.1.6, which requires Python 1.5.2 or higher, and has the following > stats:- > > 0 downloads in the last day > 0 downloads in the last week > 0 downloads in the last month > > I wish I could vent my feelings regarding your comments earlier in this > thread but I won't, as apparently core developers can say what they like > with no comeback, I don't think that's fair. Several people pointed out that Stefan's initial email was off-topic and somewhat rude, but was probably given some slack due to the fact that having deployments to the Cheeseshop fail can be frustrating (leeway I think anyone posting here would have received). At this point I think there's nothing new to be said and unless someone wants to take a more drastic step like a formal CoC complaint or calling for the heads of the management of distutils-sig on spikes, this thread has run its course. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Yearly PyPI breakage
Donald Stufft stufft.io> writes: > > Technically, he > > didn't gloat, but suddenly legal advice was apparently readily available. > > > > https://pypi.python.org/pypi/m3-cdecimal > > > > I'm not going to respond to the rest of this, because I don't think it's > possible for you and me to have a constructive discussion on these other > issues. However, I do want to point out that the PSF is the legal entity behind > PyPI itself and Van is both a board member and a lawyer. I don't recall what > exactly was discussed with who about m3-cdecimal, but it's completely > reasonable that when a legal question comes up with PyPI that we consult the > PSF board members, particularly the ones who are lawyers. It is not reasonable at all. A normal human being would try to consider first if an author has moral rights as opposed to legal rights and maybe pick up the phone or use private email instead of escalating everything to Twitter. Also, what was discussed was not whether the PSF had any right to remove m3-cdecimal but rather whether *I* had any rights to *demand* the removal. People concluded gleefully that I hadn't any (I still think they're mistaken and an enterprising Oracle lawyer could come to a different conclusion, but that's besides the point). Stefan Krah ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Yearly PyPI breakage
On Fri, May 06, 2016 at 12:03:48AM +, Brett Cannon wrote: > Is there something to contemplate in here? I dislike posting questions > instead of answers, but it seems apparent there is a problem here and it > continues to remain unaddressed. > This is whole thread is off-topic precisely because all of this is > discussed -- in the open -- on distutils-sig and decided there. If > people feel changes need to be made like broadcasting to a wider > audience when a change occurs, then please bring it up on > distutils-sig. I respectfully disagree, as this has been the default response applied for years, and it seems friction and dissemination have not been improved by it. Packaging is not some adjunct technicality, anyone learning Python in the past few years at least has been taught pip within the first week. > But if people choose not to participate then they are implicitly > delegating decision powers to those who do participate I believe this is also practically rhetorical in nature. I've watched the wars on distutils-sig for many years now, and the general strategy is that beyond minor outside influence, the process there is occupied by few individuals who are resistant to outside change. Outside influence is regularly met with essay-length reponses and tangential minutia until the energy of the challenge is expended. As an example, one common argument is that "Donald is overworked", however as an example, I offered a very long time ago to implement full text indexing for PyPI search. At the time I belive I was told such things weren't necessary, only to learn a few years later that Donald himself implemented the same function, and it suffers from huge latency and accuracy issues in the meantime. The solution to those problems is of course the ever-delayed rewrite. Over on distutils-sig, one will learn that a large amount of effort has been poured into a rewrite of PyPI (an effort going on years now), however the original codebase was not far from rescue (I had a local copy almost entirely ported to Flask in a few days). There is no reason why this effort nor any other (like full text search) should be used, as it often is, as an argument in the decisionmaking process that largely governs how PyPI and pip have worked in the recent years, yet it only takes a few glances at the archives to demonstrate that it regularly is. David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Yearly PyPI breakage
Brett Cannon python.org> writes: > This is whole thread is off-topic precisely because all of this is discussed -- in the open -- on distutils-sig and decided there. If people feel changes need to be made like broadcasting to a wider audience when a change occurs, then please bring it up on distutils-sig. But if people choose not to participate then they are implicitly delegating decision powers to those who do participate (which is totally fine and I'm not implying that if people don't participate they are doing something wrong). Participating there, especially for a non-native speaker, is basically a full-time job. You're met with a large number of extremely lengthy posts that would require an incredible amount of time to respond to in a careful manner. And ultimately it is the persons that Guido delegated the authority to who decide everything. I think many people have concluded that the influence/time ratio is too low to be worth it. Also I don't know any other development group who is a) that quick in trying to suppress any "off-topic" discussions and b) constantly uses venues outside of the Python mailing lists to steer and manipulate public opinion. Stefan Krah ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Yearly PyPI breakage
> On May 5, 2016, at 8:35 PM, David Wilson wrote: > > On Fri, May 06, 2016 at 12:03:48AM +, Brett Cannon wrote: > >>Is there something to contemplate in here? I dislike posting questions >>instead of answers, but it seems apparent there is a problem here and it >>continues to remain unaddressed. > >> This is whole thread is off-topic precisely because all of this is >> discussed -- in the open -- on distutils-sig and decided there. If >> people feel changes need to be made like broadcasting to a wider >> audience when a change occurs, then please bring it up on >> distutils-sig. > > I respectfully disagree, as this has been the default response applied > for years, and it seems friction and dissemination have not been > improved by it. Packaging is not some adjunct technicality, anyone > learning Python in the past few years at least has been taught pip > within the first week. > > >> But if people choose not to participate then they are implicitly >> delegating decision powers to those who do participate > > I believe this is also practically rhetorical in nature. I've watched > the wars on distutils-sig for many years now, and the general strategy > is that beyond minor outside influence, the process there is occupied by > few individuals who are resistant to outside change. Outside influence > is regularly met with essay-length reponses and tangential minutia until > the energy of the challenge is expended. Honestly, I just don't think this is an honest characterization. It is true that in general there are few people who bother to put in the effort to take a proposal from start to finish including actually writing the code to make such a thing happen. The problem of packaging is a particularly hard one where it's difficult to make trade offs because unlike other systems, people are sort of locked into using whatever the popular system is. If asyncio doesn't suite everyone that's fine it's not hard for them to go and switch and use Twisted, Tornado, gevent, eventlet, curio, etc etc but it's not very realistic for someone to opt out of the packaging ecosystem. In addition, it's much like something like HTTP or SMTP or the such where once you add some feature, it becomes incredibly difficult to ever remove it if you end up needing to (case in point, this thread and off site hosting), so we tend to over scrutinize changes wherever we can to try and make sure we *really* understand what the tradeoffs we're making are. Just as an example, it took a year and a half for PEP 440 to be standardized which is for something as bite sized as version numbers and PEP 440 was a continuation of the stalled PEP 386. The most time consuming part of PEP 440 was trying our new rules against every single version that existed on PyPI and minimizing the breakage. Even then, we've had several recent PEPs go through (manylinux1, environment markers, requirements) from people willing to do so. > > As an example, one common argument is that "Donald is overworked", > however as an example, I offered a very long time ago to implement full > text indexing for PyPI search. At the time I belive I was told such > things weren't necessary, only to learn a few years later that Donald > himself implemented the same function, and it suffers from huge latency > and accuracy issues in the meantime. The solution to those problems is > of course the ever-delayed rewrite. I don't remember the specific details around your proposal, but I'm pretty sure that *I* never told you that "such things were not necessary" since I've never held that opinion to my memory. What I have found [1][2] (to try and refresh my memory) are threads from you that went largely unanswered in April of 2013, which was right at the time I was heavily focused on getting PyPI setup behind Fastly and wasn't really paying attention to much else. I don't see anything else from you about it until September of 2015 when you offered your help again and at that point I told you that we had already switched to using Elasticsearch. In those two years since your initial offer, and then your follow up in 2015 I do not see any pull request to the PyPI code base from you (which, assuming they were reasonable would have been merged), however I do see the PR [3] from Ernest (No, I didn't implement the search) which got merged and deployed. My experience is that people are often willing to *offer* help with PyPI, but then they quickly disappear once they start to actually try and hack on it's code base and realize how difficult it is to work with. That experience tends to mean that I don't really get super excited when someone shows interest in helping because it rarely actually manifests. I think we've had more people contribute to Warehouse in the last year than we've *ever* had contribute to the legacy PyPI code base, which I think says a lot about the decision to switch. > > Over on distutils-sig, one will learn that a large amount of effort has > been
