Re: fileinput
Le lundi 28 octobre 2019 11:48:29 UTC+1, Peter J. Holzer a écrit :
> On 2019-10-25 22:12:23 +0200, Pascal wrote:
> > for line in fileinput.input(source):
> > print(line.strip())
> >
> > ---
> >
> > python3.7.4 myscript.py myfile.log
> > Traceback (most recent call last):
> > ...
> > UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe8 in position 799:
> > invalid continuation byte
> [...]
> > for line in fileinput.input(source,
> > openhook=fileinput.hook_encoded("utf-8", "ignore")):
> > print(line.strip())
>
> The file you were trying to read was obviously not encoded in UTF-8,
> since you got a decode error.
>
> So the first question you should ask is:
>
> Is it supposed to be encoded in UTF-8 (and just corrupted) or is in
> supposed to be encoded in something else (e.g. iso-8859-1 or win-1252)?
>
> If it is supposed to be in UTF-8 but may contain errors, ignoring errors
> may be reasonable.
>
> If is supposed to be something else, determine what that "something
> else" actually is, and use that.
>
> hp
>
> --
>_ | Peter J. Holzer| we build much bigger, better disasters now
> |_|_) || because we have much more sophisticated
> | | | h...@hjp.at | management tools.
> __/ | http://www.hjp.at/ | -- Ross Anderson
Re: fileinput
When you are reading file from stdin, fileinput doesn't open the file.
Python open the stdin. So openhook doesn't affect to stdin.
You can use stdin.reconfigure() to change encoding and error handler
of the stdin.
On Tue, Oct 29, 2019 at 6:31 PM wrote:
>
> Le lundi 28 octobre 2019 11:48:29 UTC+1, Peter J. Holzer a écrit :
> > On 2019-10-25 22:12:23 +0200, Pascal wrote:
> > > for line in fileinput.input(source):
> > > print(line.strip())
> > >
> > > ---
> > >
> > > python3.7.4 myscript.py myfile.log
> > > Traceback (most recent call last):
> > > ...
> > > UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe8 in position 799:
> > > invalid continuation byte
> > [...]
> > > for line in fileinput.input(source,
> > > openhook=fileinput.hook_encoded("utf-8", "ignore")):
> > > print(line.strip())
> >
> > The file you were trying to read was obviously not encoded in UTF-8,
> > since you got a decode error.
> >
> > So the first question you should ask is:
> >
> > Is it supposed to be encoded in UTF-8 (and just corrupted) or is in
> > supposed to be encoded in something else (e.g. iso-8859-1 or win-1252)?
> >
> > If it is supposed to be in UTF-8 but may contain errors, ignoring errors
> > may be reasonable.
> >
> > If is supposed to be something else, determine what that "something
> > else" actually is, and use that.
> >
> > hp
> >
> > --
> >_ | Peter J. Holzer| we build much bigger, better disasters now
> > |_|_) || because we have much more sophisticated
> > | | | h...@hjp.at | management tools.
> > __/ | http://www.hjp.at/ | -- Ross Anderson
Re: fileinput
Le mardi 29 octobre 2019 10:34:22 UTC+1, Inada Naoki a écrit :
> When you are reading file from stdin, fileinput doesn't open the file.
> Python open the stdin. So openhook doesn't affect to stdin.
>
> You can use stdin.reconfigure() to change encoding and error handler
> of the stdin.
>
> On Tue, Oct 29, 2019 at 6:31 PM wrote:
> >
> > Le lundi 28 octobre 2019 11:48:29 UTC+1, Peter J. Holzer a écrit :
> > > On 2019-10-25 22:12:23 +0200, Pascal wrote:
> > > > for line in fileinput.input(source):
> > > > print(line.strip())
> > > >
> > > > ---
> > > >
> > > > python3.7.4 myscript.py myfile.log
> > > > Traceback (most recent call last):
> > > > ...
> > > > UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe8 in position
> > > > 799:
> > > > invalid continuation byte
> > > [...]
> > > > for line in fileinput.input(source,
> > > > openhook=fileinput.hook_encoded("utf-8", "ignore")):
> > > > print(line.strip())
> > >
> > > The file you were trying to read was obviously not encoded in UTF-8,
> > > since you got a decode error.
> > >
> > > So the first question you should ask is:
> > >
> > > Is it supposed to be encoded in UTF-8 (and just corrupted) or is in
> > > supposed to be encoded in something else (e.g. iso-8859-1 or win-1252)?
> > >
> > > If it is supposed to be in UTF-8 but may contain errors, ignoring errors
> > > may be reasonable.
> > >
> > > If is supposed to be something else, determine what that "something
> > > else" actually is, and use that.
> > >
> > > hp
> > >
> > > --
> > >_ | Peter J. Holzer| we build much bigger, better disasters now
> > > |_|_) || because we have much more sophisticated
> > > | | | h...@hjp.at | management tools.
> > > __/ | http://www.hjp.at/ | -- Ross Anderson
ANN: distlib 0.3.0 released on PyPI
I've recently released version 0.3.0 of distlib on PyPI [1]. For newcomers,distlib is a library of packaging functionality which is intended to beusable as the basis for third-party packaging tools. The main changes in this release are as follows: * Partially addressed #102: modules attribute of InstalledDistribution was incorrectly computed as a list of bytes, rather than a list of str. This has now been corrected. * Updated Locator._get_digest to check PyPI JSON responses for a "digests" dictionary before trying "algo_digest" keys. Thanks to Jeffery To for the patch. * Fixed #123: Improved error message if a resource isn't found. * Fixed #124: Stopped norm-casing the executable written into shebangs, as it doesn't work for some non-ASCII paths. * Fixed #125: Updated launchers with versions that correctly report errors containing non-ASCII characters. The updated launchers now also support relative paths (see http://bit.ly/2JxmOoi for more information). * Fixed #127: Allowed hyphens in flags in export specifications. * Changed Python version handling to accommodate versions like e.g. 3.10 (no longer assume a version X.Y where X and Y are single digits). A more detailed change log is available at [2]. Please try it out, and if you find any problems or have any suggestions for improvements,please give some feedback using the issue tracker! [3] Regards, Vinay Sajip [1] https://pypi.org/project/distlib/0.3.0/[2] https://distlib.readthedocs.io/en/0.3.0/[3] https://bitbucket.org/pypa/distlib/issues/new -- https://mail.python.org/mailman/listinfo/python-list
Re: keying by identity in dict and set
Steve White writes: > Yes, there are several options, but they all involve an extra layer > that detracts between the interface I am building and my user's code. Do the wrapping behind the application interface. And in a private email you told me that this is for a very special case -- which likely means "rarely used". For such cases, a bit "detraction" might be acceptable (much more acceptable than a counter-intuitive behaviour of a standard data type). > In this situation, the objects being used as keys are conceptually the > unique entities that the user deals with, even if their data is > non-unique. And I do not want to subject the user to the un-pythonic > use of some operator other than '==' to determine their equivalence. One possibility would be to have a special class for those objects which implements both "__eq__" and "__hash__" via the "id" function. > As near as I can tell, returning the id() in __hash__() results in a > perfect hash key. I really want to know if that is true. Such a "__hash__" implementation is almost surely perfect (unless your objects' lifetime exceeds the process lifetime) **BUT** nevertheless define "__eq__" in the same way. This is because the hash value is not directly used to determine a "dict" slot; to conserve space, the "dict" size determines the number of available slots; therefore, even with a perfect hash, two keys (with different hash values) may end up in the same "dict" slot. It is an implementation details whether Python distinguishes keys in the same slot using only "__eg__" or "__hash__" and "__eq__" (implementation detail means that different Python implementations may behave differently). Thus, follow the documentation and define "__eq__" and "__hash__" in a compatible way. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: keying by identity in dict and set
Steve White writes: > ... > A little documentation would have saved me personally days of work. > It would be helpful to know: > * under what conditions can one expect a "perfect hash", that is, > one where __eq__() will never be called? Never expect it: keys with different hash values may end up in the same "dict" slot - and then "__eq__" may be used for disambiguation even with a perfect hash function. > * is it sufficient to return the value of the key object's id() > function to produce a perfect hash? Usually. Exceptions are (maybe among others): persistent objects (i.e. objects which live longer than a process), situations during shutdown (during shutdown, an object may be released even if there are still references to it; it might be possible that during this phase the same address is reused even if at some other place there is still an implicit use of the old object). > * when might it be useful to consider keying by identity? Suboptimal question. Follow Python's standard "dict" key management paradigm (which is equality based). If this does not fit, then look for the approach that fits your **special** case. > * what are the limitations of programming this way? With "this way", you mean "identity based dicts"? Then, you have already got several limitations in this thread. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Sudden changes in idle python and my laptop
nashrahmehar11 writes: > Suddenly,my idle python started to behave abnormally and when i closed and > tried to start it again,then it gave the above message. This is a text only mailing list. You must therefore provide all information in text - you cannot refer to attachments. You might consider uploading images to an appropriate site (maybe "pastebin") and add a corresponding link to your message. But it usually is much preferable to you extract the important information as text and include it explicitly into your message. -- https://mail.python.org/mailman/listinfo/python-list
Re: Internal Server Error when trying to access WebTours (an Application built in Strawberry perl)
Kishore m writes:
> I have installed Python 64 bit 2 days back and had to uninstall Python as I
> got below error with webtours application built in Strawberry Perl which im
> using from an year without any issue.
>
> *Problem Statement:*
> Internal Server Error when trying to access WebTours
"Internal Server Error" is a server side ("WebTours" in your case)
error. It might have been triggered by the client side (that
is likely your application) by some bad use.
> *Error message in webtours server logs:*
>
> [Sun Oct 27 06:20:11 2019] [error] [client 127.0.0.1] (OS 2)The system
> cannot find the file specified. : couldn't create child process: 720002:
> welcome.pl, referer: http://127.0.0.1:1080/WebTours/index.htm
This error indicates the "WebTours" has not been set up properly.
This is not a Python problem. You likely will get better help
somewhere else.
--
https://mail.python.org/mailman/listinfo/python-list
