Re: XML Considered Harmful
Jon Ribbens writes: > On 2021-09-21, Pete Forman wrote: >> CSV is quite good as a lowest common denominator exchange format. I >> say quite because I would characterize it by 8 attributes and you >> need to pick a dialect such as MS Excel which sets out what those >> are. XML and JSON are controlled much better. You can easily verify >> that you conform to those and guarantee that *any* conformant parser >> can read your content. XML is more powerful in that repect than JSON >> in that you can define and enforce schemas. In your case the fuel >> name, UOM, etc. can be validated with standard tools. In JSON all >> that checking is entirely handled by the consuming program(s). > > That's not true. You can use "JSON Schema" to create a schema for > validating JSON files, and there appear to be at least four > implementations in Python. Fair point. It has been a while since I looked at JSON schemas and they were rather less mature then. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: XML Considered Harmful
"Michael F. Stemper" writes: > On 21/09/2021 13.49, alister wrote: >> On Tue, 21 Sep 2021 13:12:10 -0500, Michael F. Stemper wrote: > It's my own research, so I can give myself the data in any format that I > like. > >> as far as I can see the main issue with XML is bloat, it tries to do >> too many things & is a very verbose format, often the quantity of >> mark-up can easily exceed the data contained within it. other formats >> such a JSON & csv have far less overhead, although again not always >> suitable. > > I've heard of JSON, but never done anything with it. Then you should certainly try to get a basic understanding of it. One thing JSON shares with XML is that it is best left to machines to produce and consume. Because both can be viewed in a text editor there is a common misconception that they are easy to edit. Not so, commas are a common bugbear in JSON and non-trivial edits in (XML unaware) text editors are tricky. Consider what overhead you should worry about. If you are concerned about file sizes then XML, JSON and CSV should all compress to a similar size. > How does CSV handle hierarchical data? For instance, I have > generators[1], each of which has a name, a fuel and one or more > incremental heat rate curves. Each fuel has a name, UOM, heat content, > and price. Each incremental cost curve has a name, and a series of > ordered pairs (representing a piecewise linear curve). > > Can CSV files model this sort of situation? The short answer is no. CSV files represent spreadsheet row-column values with nothing fancier such as formulas or other redirections. CSV is quite good as a lowest common denominator exchange format. I say quite because I would characterize it by 8 attributes and you need to pick a dialect such as MS Excel which sets out what those are. XML and JSON are controlled much better. You can easily verify that you conform to those and guarantee that *any* conformant parser can read your content. XML is more powerful in that repect than JSON in that you can define and enforce schemas. In your case the fuel name, UOM, etc. can be validated with standard tools. In JSON all that checking is entirely handled by the consuming program(s). >> As in all such cases it is a matter of choosing the most apropriate tool >> for the job in hand. > > Naturally. That's what I'm exploring. You might also like to consider HDF5. It is targeted at large volumes of scientific data and its capabilities are well above what you need. MATLAB, Octave and Scilab use it as their native format. PyTables and h2py provide Python/NumPy bindings to it. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Replacement for pygtk?
Akkana Peck writes: > Grant Edwards writes: >> * PyQt -- I run Gtk-centric Linux systems, and the second you try to >>use one Qt widget, it always seems to pull in hundreds of packages >>that take a week to build. > > I haven't generally found that about PyQt. Most KDE apps do pull in > hundreds of packages, but I haven't had to install that many just to > use PyQt. Once you have one Qt app in a Gtk DE, or vice versa, then you have taken most of the hit for packages. I doubt that many people run pure versions of either. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: What is your experience porting Python 2.7.x scripts to Python 3.x?
Robin Becker writes: > On 22/01/2019 19:00, Schachner, Joseph wrote: > .. >> For anyone who has moved a substantial bunch of Python 2 to Python 3, >> can you please reply with your experience? Did you run into any >> issues? Did 2to3 do its job well, or did you have to review its >> output to eliminate some working but silly thing? >> > ,.. > I did the port of reportlab (www.reportlab.com) from code supporting > 2.x only x>=3 to a version which supported 2.7.z & >=3.3. The > reportlab toolkit was then about 14 years old and had (and still has > lots of cruft). The port effort began 20130215 and ended 20140326 ie > 13 months. There were 333 commits on the branch. I used 2to3, but not > six. Because we needed to maintain 2.7 and >=3.3 there were quite a > few issues related to simple things like iterkeys/values/items <--> > keys/values/items removal of xrange etc etc. > > Maintaining compatible extensions is also hard. Pdf production > requires byte output and was already quite messy because reportlab > supported both utf8 and unicode inputs; it hasn't got a lot easier. > > As for performance the 3.x runs were generally slower than 2.7, but I > think that situation has changed with 3.6 & 3.7 (for the reportlab > tests on windows 2.7 takes 68.7", 3.4 83.8", 3.5 77.0", 3.6 61.5" & > 3.7 60.9"). > > At some point reportlab will be made 3.x only which will require more > effort. Packages like reportlab with a need to support both Python 2 and 3 end up with the worst of both worlds. The initial drive for Py3k was to drop cruft that had accumulated over the years. Mixing old and new hampers your ability to write clean 3 code. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: This newsgroup (comp.lang.python) may soon be blocked by Google Groups
mark...@gmail.com writes: > On Thursday, February 1, 2018 at 6:01:58 PM UTC+1, superchromix wrote: >> Our own programming discussion newsgroup, located at >> comp.lang.idl-pvwave, started receiving spam messages several months >> ago. >> >> Two weeks ago, access to comp.lang.idl-pvwave was blocked by Google >> Groups. >> >> When trying to access comp.lang.idl-pvwave, a message is now >> displayed, stating that the group owner needs to remove the spam, >> and can then apply to Google in order to have access reinstated. >> >> However, old public Usenet groups like this have no owner. The >> comp.lang.idl-pvwave group is more than 20 years old. Hence, there >> is no way to unblock the group. >> >> This is a serious problem, since the entire collection of postings >> going back many years has been blocked, no just the spam. This >> resource is frequently used by IDL programmers. >> >> Seeing the spam postings in this newsgroup, I expect something >> similar may happen to comp.lang.python, soon. > > The problem I have now is that there is no public, searchable archive > of comp.lang.idl-pvwave available. This was the real benefit of Google > groups, from my point of view. > > There is something called "narkive", but its search function seems to > be broken, and it doesn't archive very far back in time. A couple of other mail archivers are: https://www.mail-archive.com https://marc.info -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: how to read in the newsreader
Thomas Jollans writes: > On 16/10/17 20:02, Pete Forman wrote: >> Thomas Jollans writes: >> >>> On 2017-10-16 08:48, Pete Forman wrote: >>>> Andrew Z writes: >>>> >>>>> hmm. i did do that. maybe just a delay. >>>>> I'll see how it will go tomorrow then. Thank you gents. >>>>> >>>>> On Mon, Oct 16, 2017 at 12:30 AM, Chris Angelico wrote: >>>>> >>>>>> On Mon, Oct 16, 2017 at 3:19 PM, Andrew Z wrote: >>>>>>> Michael, that's what i use too - gmail. But i get the digest only >>>>>>> and can't really reply that way. i was hoping to get the >>>>>>> mail.python.org list >>>>>> >>>>>> Turn off digests then. Easy! >>>> >>>> If you do stick with a digest then check your newsreader for a feature >>>> to expand it. Then you can read and reply as if you were getting >>>> individual posts. >>>> >>> That exists? How does it work? >> >> The Gnus newsreader in Emacs allows you to type C-d on a digest to run >> gnus-summary-enter-digest-group. That then behaves the same as if you >> opened any other summary such as a regular Usenet group. >> > > Does it set the References header correctly when replying? Sorry, I am not in a position to test. The only digest I subscribe to is comp.risks. The only messsage id in that is a single one for the whole digest. Each article only has date, subject and from headers. You would need to look inside a Python digest to see if it carries more headers for the articles. If they are not present then they cannot be used when composing a reply. -- Pete Forman https://payg.pythonanywhere.com -- https://mail.python.org/mailman/listinfo/python-list
Re: how to read in the newsreader
Thomas Jollans writes: > On 2017-10-16 08:48, Pete Forman wrote: >> Andrew Z writes: >> >>> hmm. i did do that. maybe just a delay. >>> I'll see how it will go tomorrow then. Thank you gents. >>> >>> On Mon, Oct 16, 2017 at 12:30 AM, Chris Angelico wrote: >>> >>>> On Mon, Oct 16, 2017 at 3:19 PM, Andrew Z wrote: >>>>> Michael, that's what i use too - gmail. But i get the digest only >>>>> and can't really reply that way. i was hoping to get the >>>>> mail.python.org list >>>> >>>> Turn off digests then. Easy! >> >> If you do stick with a digest then check your newsreader for a feature >> to expand it. Then you can read and reply as if you were getting >> individual posts. >> > That exists? How does it work? The Gnus newsreader in Emacs allows you to type C-d on a digest to run gnus-summary-enter-digest-group. That then behaves the same as if you opened any other summary such as a regular Usenet group. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: how to read in the newsreader
Andrew Z writes: > hmm. i did do that. maybe just a delay. > I'll see how it will go tomorrow then. Thank you gents. > > On Mon, Oct 16, 2017 at 12:30 AM, Chris Angelico wrote: > >> On Mon, Oct 16, 2017 at 3:19 PM, Andrew Z wrote: >> > Michael, that's what i use too - gmail. But i get the digest only >> > and can't really reply that way. i was hoping to get the >> > mail.python.org list >> >> Turn off digests then. Easy! If you do stick with a digest then check your newsreader for a feature to expand it. Then you can read and reply as if you were getting individual posts. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Case-insensitive string equality
Steven D'Aprano writes:
> Three times in the last week the devs where I work accidentally
> introduced bugs into our code because of a mistake with case-insensitive
> string comparisons. They managed to demonstrate three different failures:
>
> # 1
> a = something().upper() # normalise string
> ... much later on
> if a == b.lower(): ...
>
>
> # 2
> a = something().upper()
> ... much later on
> if a == 'maildir': ...
>
>
> # 3
> a = something() # unnormalised
> assert 'foo' in a
> ... much later on
> pos = a.find('FOO')
>
>
>
> Not every two line function needs to be in the standard library, but I've
> come to the conclusion that case-insensitive testing and searches should
> be. I've made these mistakes myself at times, as I'm sure most people
> have, and I'm tired of writing my own case-insensitive function over and
> over again.
>
>
> So I'd like to propose some additions to 3.7 or 3.8. If the feedback here
> is positive, I'll take it to Python-Ideas for the negative feedback :-)
>
>
> (1) Add a new string method, which performs a case-insensitive equality
> test. Here is a potential implementation, written in pure Python:
>
>
> def equal(self, other):
> if self is other:
> return True
> if not isinstance(other, str):
> raise TypeError
> if len(self) != len(other):
> return False
> casefold = str.casefold
> for a, b in zip(self, other):
> if casefold(a) != casefold(b):
> return False
> return True
>
> Alternatively: how about a === triple-equals operator to do the same
> thing?
>
>
>
> (2) Add keyword-only arguments to str.find and str.index:
>
> casefold=False
>
> which does nothing if false (the default), and switches to a case-
> insensitive search if true.
>
>
>
>
> Alternatives:
>
> (i) Do nothing. The status quo wins a stalemate.
>
> (ii) Instead of str.find or index, use a regular expression.
>
> This is less discoverable (you need to know regular expressions) and
> harder to get right than to just call a string method. Also, I expect
> that invoking the re engine just for case insensitivity will be a lot
> more expensive than a simple search need be.
>
> (iii) Not every two line function needs to be in the standard library.
> Just add this to the top of every module:
>
> def equal(s, t):
> return s.casefold() == t.casefold()
>
>
> That's the status quo wins again. It's an annoyance. A small
> annoyance, but multiplied by the sheer number of times it happens, it
> becomes a large annoyance. I believe the annoyance factor of
> case-insensitive comparisons outweighs the "two line function"
> objection.
>
> And the two-line "equal" function doesn't solve the problem for find
> and index, or for sets dicts, list.index and the `in` operator either.
>
>
> Unsolved problems:
>
> This proposal doesn't help with sets and dicts, list.index and the `in`
> operator either.
>
>
>
> Thoughts?
This seems to me to be rather similar to sort() and sorted(). How about
giving equals() an optional parameter key, and perhaps the older cmp?
Using casefold or upper or lower would satisfy many use cases but also
allow Unicode or more locale specific normalization to be applied.
The shortcircuiting in a character based comparison holds little appeal
for me. I generally find that a string is a more useful concept than a
collection of characters.
+1 for using an affix in the name to represent a normalized version of
the input.
--
Pete Forman
--
https://mail.python.org/mailman/listinfo/python-list
Re: What's with all of the Case Solution and Test Bank nonsense posts?
Chris Angelico writes: > On Tue, Jul 11, 2017 at 4:12 AM, Michael Torrie wrote: >> On 07/10/2017 11:05 AM, Paul Rubin wrote: >>> Michael Torrie writes: >>>>> can you get a newsreader to work with a https news service? >>>> No. A newsreader works with NNTP protocol. >>> >>> Traditionally NNTP over SSL was done on port 563. Some feeds now >>> also provide it on 443 to get around client-side firewall hassles. >> >> Yes but that's not via https. > > What's the meaning of "https news service" then? If it's netnews, it's > NNTP, not HTTP. If it just happens to be a web app that carries > information from a newsgroup, then that's not a news service, it's a > web forum, and there's no such thing as a generic web forum API. RFC 4642 (updated by RFC 8143) describes the use of TLS with NNTP. It enhances the connection between NNTP client and server, primarily with encryption but optionally with other benefits. Of course it does nothing to improve the content of Usenet. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Who still supports recent Python on shared hosting
John Nagle writes: > I'm looking for shared hosting that supports > at least Python 3.4. > > Hostgator: Highest version is Python 3.2. > Dreamhost: Highest version is Python 2.7. > Bluehost: Install Python yourself. > InMotion: Their documentation says 2.6. > > Is Python on shared hosting dead? > I don't need a whole VM and something I > have to sysadmin, just a small shared > hosting account. I use OpenShift from Red Hat on their free hosting package. They offer Python 3.5, 3.3 and 2.7. -- Pete Forman https://payg-petef.rhcloud.com -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP 393 vs UTF-8 Everywhere
Marko Rauhamaa writes: >> py> low = '\uDC37' > > That should raise a SyntaxError exception. Quite. My point was that with older Python on a narrow build (Windows and Mac) you need to understand that you are using UTF-16 rather than Unicode. On a wide build or Python 3.3+ then all is rosy. (At this point I'm tempted to put in a winky emoji but that might push the internal representation into UCS-4.) -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP 393 vs UTF-8 Everywhere
Steve D'Aprano writes:
> [...]
> Another factor which I didn't see discussed anywhere is that Python
> strings treat surrogates as normal code points. I believe that would
> be troublesome for a UTF-8 implementation:
>
> py> '\uDC37'.encode('utf-8')
> Traceback (most recent call last):
> File "", line 1, in
> UnicodeEncodeError: 'utf-8' codec can't encode character '\udc37' in
> position 0: surrogates not allowed
>
> but of course with a UCS-2 or UTF-32 implementation it is trivial: you
> just treat the surrogate as another code point like any other.
Thanks for a very thorough reply, most useful. I'm going to pick you up
on the above, though.
Surrogates only exist in UTF-16. They are expressly forbidden in UTF-8
and UTF-32. The rules for UTF-8 were tightened up in Unicode 4 and RFC
3629 (2003). There is CESU-8 if you really need a naive encoding of
UTF-16 to UTF-8-alike.
py> low = '\uDC37'
is only meaningful on narrow builds pre Python 3.3 where the user must
do extra to correctly handle characters outside the BMP.
--
Pete Forman
https://payg-petef.rhcloud.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: PEP 393 vs UTF-8 Everywhere
MRAB writes: > As someone who has written an extension, I can tell you that I much > prefer dealing with a fixed number of bytes per codepoint than a > variable number of bytes per codepoint, especially as I'm also > supporting earlier versions of Python where that was the case. At the risk of sounding harsh, if supporting variable bytes per codepoint is a pain you should roll with it for the greater good of supporting users. PEP 393 / Python 3.3 required extension writers to revisit their access to strings. My explicit question was about why PEP 393 was adopted to replace the deficient old implementations rather than another approach. The implicit question is whether a UTF-8 internal representation should replace that of PEP 393. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP 393 vs UTF-8 Everywhere
Chris Kaynor writes: > On Fri, Jan 20, 2017 at 2:35 PM, Pete Forman wrote: >> Can anyone point me at a rationale for PEP 393 being incorporated in >> Python 3.3 over using UTF-8 as an internal string representation? >> I've found good articles by Nick Coghlan, Armin Ronacher and others >> on the matter. What I have not found is discussion of pros and cons >> of alternatives to the old narrow or wide implementation of Unicode >> strings. > > The PEP itself has the rational for the problems with the narrow/wide > idea, the quote from https://www.python.org/dev/peps/pep-0393/: There > are two classes of complaints about the current implementation of the > unicode type:on systems only supporting UTF-16, users complain that > non-BMP characters are not properly supported. On systems using UCS-4 > internally (and also sometimes on systems using UCS-2), there is a > complaint that Unicode strings take up too much memory - especially > compared to Python 2.x, where the same code would often use ASCII > strings (i.e. ASCII-encoded byte strings). With the proposed approach, > ASCII-only Unicode strings will again use only one byte per character; > while still allowing efficient indexing of strings containing non-BMP > characters (as strings containing them will use 4 bytes per > character). > > Basically, narrow builds had very odd behavior with non-BMP > characters, namely that indexing into the string could easily produce > mojibake. Wide builds used quite a bit more memory, which generally > translates to reduced performance. I'm taking as a given that the old way was often sub-optimal in many scenarios. My questions were about the alternatives, and why PEP 393 was chosen over other approaches. >> ISTM that most operations on strings are via iterators and thus >> agnostic to variable or fixed width encodings. How important is it to >> be able to get to part of a string with a simple index? Just because >> old skool strings could be treated as a sequence of characters, is >> that a reason to shoehorn the subtleties of Unicode into that model? > > I think you are underestimating the indexing usages of strings. Every > operation on a string using UTF8 that contains larger characters must > be completed by starting at index 0 - you can never start anywhere > else safely. rfind/rsplit/rindex/rstrip and the other related reverse > functions would require walking the string from start to end, rather > than short-circuiting by reading from right to left. With indexing > becoming linear time, many simple algorithms need to be written with > that in mind, to avoid n*n time. Such performance regressions can > often go unnoticed by developers, who are likely to be testing with > small data, and thus may cause (accidental) DOS attacks when used on > real data. The exact same problems occur with the old narrow builds > (UTF16; note that this was NOT implemented in those builds, however, > which caused the mojibake problems) as well - only a UTF32 or PEP393 > implementation can avoid those problems. I was asserting that most useful operations on strings start from index 0. The r* operations would not be slowed down that much as UTF-8 has the useful property that attempting to interpret from a byte that is not at the start of a sequence (in the sense of a code point rather than Python) is invalid and so quick to move over while working backwards from the end. The only significant use of an index dereference that I could come up with was the result of a find() or index(). I put out this public question so that I could be enclued as to other uses. My personal experience is that in most cases where I might consider find() that I end up using re and use the return from match groups which has copies of the (sub)strings that I want. > Note that from a user (including most developers, if not almost all), > PEP393 strings can be treated as if they were UTF32, but with many of > the benefits of UTF8. As far as I'm aware, it is only developers > writing extension modules that need to care - and only then if they > need maximum performance, and thus cannot convert every string they > access to UTF32 or UTF8. PEP 393 already says that "the specification chooses UTF-8 as the recommended way of exposing strings to C code". -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
PEP 393 vs UTF-8 Everywhere
Can anyone point me at a rationale for PEP 393 being incorporated in Python 3.3 over using UTF-8 as an internal string representation? I've found good articles by Nick Coghlan, Armin Ronacher and others on the matter. What I have not found is discussion of pros and cons of alternatives to the old narrow or wide implementation of Unicode strings. ISTM that most operations on strings are via iterators and thus agnostic to variable or fixed width encodings. How important is it to be able to get to part of a string with a simple index? Just because old skool strings could be treated as a sequence of characters, is that a reason to shoehorn the subtleties of Unicode into that model? -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: lxml and xpath(?)
Peter Otten <__pete...@web.de> writes:
> root = etree.fromstring(s)
> for server in root.xpath("./server"):
> servername = server.xpath("./name/text()")[0]
When working with lxml I prefer to use this Python idiom.
servername, = server.xpath("./name/text()")
That enforces a single result. The original code will detect a lack of
results but if the query returns multiple results when only one is
expected then it silently returns the first.
--
Pete Forman
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python packages listed in PyPI
On 21 July 2016 at 07:28, Rayne wrote: > Thanks! One more question: Does "pip install" require Internet to work? Or > are all implementations already contained in the packages and so do not > require additional downloads? > pip install is downloading from https://pypi.python.org so yes you do need internet access. Having said that there are a couple of ways to feed pip. You can run a local pypi server to host previously downloaded packages or tell pip to install from a file. "pip help install" Automatic handling of additional downloads is automatic in pip. If the package you are installing requires some other packages then it will install those too. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Python packages listed in PyPI
Rayne writes: > May I know if the Python packages listed on the PyPI page > (https://pypi.python.org/pypi) are OS-independent? That is, do I > download and install the same package on both Windows and Linux The simple answer is yes. pip install will find the appropriate implementation for your OS and version of Python. If the package is pure Python then it will be the same across OS. If there is some binary content then PyPI will deliver the correct wheel (precompiled) or C/C++ source. The latter generally builds OOTB on Linux but needs extra work on Windows as that does not bundle a compiler. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: best text editor for programming Python on a Mac
Joel Goldstick writes: > On Sat, Jun 18, 2016 at 8:12 PM, Lawrence D’Oliveiro > wrote: >> On Sunday, June 19, 2016 at 11:07:23 AM UTC+12, Michael Torrie wrote: >>> >>> On 06/17/2016 05:52 PM, Chris via Python-list wrote: >>>> >>>> Any suggestions for a good open source text editor for the Mac out >>>> there? For now, I am going to stick with vim. >>> >>> Good choice. >> >> The trouble with vim/vi/whatever, is that it doesn’t work like any >> other editor on Earth. >> >> Pull up any old GUI-based editor you like, for example Windows >> (shudder) Notepad. If there are N characters in your file, then the >> insertion point can be placed at N + 1 positions: in-between two >> adjacent characters, or before the first character, or after the last >> character. And this makes sense: anything you type is inserted at the >> insertion point. All rational text editors (and word processors) work >> this way. >> >> But not vi/vim. It only lets you place your cursor *on* a character, >> not *in-between* characters. That’s why you need two separate >> insertion commands, insert-before and insert-after. And one of those >> has the interesting side effect where, if you exit insertion mode >> without inserting anything, it doesn’t put you back in the same >> position as before. Why? >> >> As to why you need insertion commands at all, that’s another thing... >> -- >> https://mail.python.org/mailman/listinfo/python-list > > I personally love vim. But its clearly an acquired taste. When you > get good at it its pretty amazing -- and no mouse. The other thing > about vim is that it is on every linux system, so you don't have to > load your editor if you are ssh-ing to some machine Both emacs and vim are powerful tools in the hands of experienced users but I would recommend neither to someone starting out who is just looking for a code-aware editor. Emacs and vim are much more than editors. I'm composing this message using Emacs/Gnus on a Mac. TRAMP is invaluable to me for my daily work. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Method Chaining
Rustom Mody writes: > On Saturday, June 18, 2016 at 5:34:30 PM UTC+5:30, Pete Forman wrote: >> Rustom Mody writes: >> [snip] >> >> One subtle difference between your two citations is that VB uses a >> leading dot. Might that lessening of ambiguity enable a future Python to >> allow this? >> >> class Foo: >> def .set(a): # equivalent to def set(self, a): >> .a = a# equivalent to self.a = a >> > > Chuckle! Heck Why not?! > But no I did not think of this Why stop there? Another long standing bugbear can be addressed with this. class Foo: def .set(.a, b) # equivalent to def set(self, a): self.a = a .c += b # equivalent to self.c += b Explicitly, that is three new syntactic items. 1) . before a method name elides the first argument of self 2) . before an argument is shorthand for assign to a member 3) . before a variable in a method body replaces self. Earlier I had proposed a new use of "with" that would have changed the binding in (3) from self to something else. That was not a good idea for two reasons. Python already provides a reasonable way to achieve that, as described in the design FAQ. The second reason is that it subverts the current "with" statement which mandates its with_item to be a context expression. "as target" is optional and so syntactic discrimination is not possible. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Method Chaining
Joonas Liik writes: > On 18 June 2016 at 15:04, Pete Forman wrote: >> Rustom Mody writes: >> >>> On Friday, June 17, 2016 at 2:58:19 PM UTC+5:30, Steven D'Aprano wrote: >>>> On Fri, 17 Jun 2016 06:13 pm, Ned Batchelder wrote: >>>> >>>> > To me, it's a toss-up. The chained version is nice in that it >>>> > removes the repetition of "g". But the unchained version is more >>>> > explicit, and avoids the awkward parenthesis. >>>> > >>>> > I think I would lean toward the unchained version. Clearly tastes >>>> > can differ. >>>> >>>> Indeed. For what it's worth, I'm ever-so-slightly leaning towards >>>> Lawrence's taste here. >>> >>> More than 'slightly' out here! >>> One thing about python OOP that irritates me is the 'self.' clutter. >>> With a Pascal/VB style with-statement its naturally taken care of >>> >>> Yeah I know there is this FAQ: >>> https://docs.python.org/2/faq/design.html#why-doesn-t-python-have-a-with-statement-for-attribute-assignments >>> >>> I consider it bogus if we allow with to mean something like: >>> https://msdn.microsoft.com/en-us/library/wc500chb.aspx >> >> One subtle difference between your two citations is that VB uses a >> leading dot. Might that lessening of ambiguity enable a future Python to >> allow this? >> >> class Foo: >> def .set(a): # equivalent to def set(self, a): >> .a = a# equivalent to self.a = a >> >> Unless it is in a with statement >> >> with obj: >> .a = 1# equivalent to obj.a = 1 >> .total = .total + 1 # obj.total = obj.total + 1 >> >> -- >> Pete Forman >> -- >> https://mail.python.org/mailman/listinfo/python-list > > the leading dot does not resolve the ambiguity that arises from: > > with ob_a: > with ob_b: > .attr_c = 42 # which object are we modifying right now? > > also refer to "javascript the bad parts" about all the edege cases > that python would surely face. > also with is allready used for context managers.. Yes, I ought not to have lumped in the with proposal with that for self. Python's design FAQ clearly explains why the language does not need that form of "with". -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: value of pi and 22/7
Lawrence D’Oliveiro writes:
> On Saturday, March 19, 2011 at 3:16:41 AM UTC+13, Grant Edwards wrote:
>>
>> On 2011-03-18, peter wrote:
>>
>>> The Old Testament (1 Kings 7,23) says ... "And he made a molten sea,
>>> ten cubits from the one brim to the other: it was round all about, and
>>> his height was five cubits: and a line of thirty cubits did compass it
>>> round about. ". So pi=3. End Of.
>>
>> There's nothing wrong with that value. The measurements were given
>> with one significant digit, so the ratio of the two measurements
>> should only have one significant digit.
>
> I’m not sure how you can write “30” with one digit...
>>> int('U', 36)
30
--
Pete Forman
--
https://mail.python.org/mailman/listinfo/python-list
Re: Method Chaining
Rustom Mody writes: > On Friday, June 17, 2016 at 2:58:19 PM UTC+5:30, Steven D'Aprano wrote: >> On Fri, 17 Jun 2016 06:13 pm, Ned Batchelder wrote: >> >> > To me, it's a toss-up. The chained version is nice in that it >> > removes the repetition of "g". But the unchained version is more >> > explicit, and avoids the awkward parenthesis. >> > >> > I think I would lean toward the unchained version. Clearly tastes >> > can differ. >> >> Indeed. For what it's worth, I'm ever-so-slightly leaning towards >> Lawrence's taste here. > > More than 'slightly' out here! > One thing about python OOP that irritates me is the 'self.' clutter. > With a Pascal/VB style with-statement its naturally taken care of > > Yeah I know there is this FAQ: > https://docs.python.org/2/faq/design.html#why-doesn-t-python-have-a-with-statement-for-attribute-assignments > > I consider it bogus if we allow with to mean something like: > https://msdn.microsoft.com/en-us/library/wc500chb.aspx One subtle difference between your two citations is that VB uses a leading dot. Might that lessening of ambiguity enable a future Python to allow this? class Foo: def .set(a): # equivalent to def set(self, a): .a = a# equivalent to self.a = a Unless it is in a with statement with obj: .a = 1# equivalent to obj.a = 1 .total = .total + 1 # obj.total = obj.total + 1 -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Format a timedelta object
Steven D'Aprano writes: > On Thu, 26 May 2016 03:28 pm, Zachary Ware wrote: > >> On Thu, May 26, 2016 at 12:16 AM, Steven D'Aprano >> wrote: >>> I have a timedelta object, and I want to display it in a nice >>> human-readable format like 03:45:17 for "three hours, forty five minutes, >>> 17 seconds". >>> >>> Is there a standard way to do this? >> >>>>> timedelta(100) >>datetime.timedelta(100) >>>>> str(timedelta(seconds=100)) >>'0:01:40' >>>>> str(timedelta(hours=100)) >>'4 days, 4:00:00' >> >> (I recently spent *way* too long trying to figure out how to properly >> format the thing before being reminded that a plain str call gives >> exactly what I was after.) > > Thanks Zach. Unfortunately, the format is not quite how I want it, so I > guess I'll have to extract the H:M:S fields manually from the seconds. It might be useful if timedelta were to get an isoformat() method. ISO 8601 specifies formats for durations; most people are familiar only with the date amd time formats. There are variations available but PnDTnHnMnS is probably the best. The biggest timedelta unit is days. Years and months are not appropriate. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
Gregory Ewing writes: > Pete Forman wrote: >> However I am coming from scientific measurements where 1.0 is the >> stored value for observations between 0.95 and 1.05. > > You only know that because you're keeping some extra information in > your head about what the 1.0 stored in your computer represents. It's > not inherent in the value itself. No, that is a real case. Floating point hardware can hold intermediate values in 80 bit registers before writing the double precision result to 8 bytes of memory. There are compiler switches available to enforce strict IEEE conformance and discard the intermediate guard digits. By adhering to those rules the results are predictable (repeatable on other hardware) but less accurate mathematically speaking. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
Ian Kelly writes: > On Mon, May 23, 2016 at 12:16 PM, Pete Forman wrote: >> Something else which I do not think has been stated yet in this >> thread is that floating point is an inexact representation. Just >> because integers and binary fractions have an exact correspondence we >> ought not to be affording them special significance. Floating point 1 >> is not the integer 1, it stands for a range of numbers some fraction >> either side of 1. > > This is not the case. Floating point 1 means exactly 1, no more and no > less. Results that aren't exactly representable get rounded to values > that are, but this does not imply that the value once rounded is > inexact. The value that 1/3 gets rounded to is exactly equal to > 6004799503160661 / 18014398509481984, no more and no less. > > Treating floating point values as inexact would require an > accumulation of the range of error. Otherwise, it would no longer be > correct to say that 1.0 * 1.0 == 1.0. The result could with equal > correctness be the next floating point number after 1.0, or the > previous value before 1.0. Continue multiplying by 1.0 and the error > creeps larger and larger. The defined result of the operation, > however, is the exact value 1.0. Let us for the sake of argument consider a floating point representation that has one decimal point of precision. It is easier to talk about than the IEEE double precision used in Python. If you are talking about the multiplicative identity element then 1.0 is exactly unity and repeated multiplication will not change the result. However I am coming from scientific measurements where 1.0 is the stored value for observations between 0.95 and 1.05. If I wish to correlate two signals that were 1.03 and 1.04 at higher precision then 1.1 is actually a reasonable value for their "correct" product, even though 1.0 is what is prescribed by IEEE-style rules because they are both stored as 1.0. I agree that errors tend to creep ever larger. IEEE rounding rules seek to minimize the error of the result but management of the accumulated error is up to the scientist / programmer, it is not part of the IEEE arithmetic. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
Ian Kelly writes: > On Mon, May 23, 2016 at 8:29 AM, Ben Bacarisse wrote: >> Ian Kelly writes: >> >>> On Mon, May 23, 2016 at 2:09 AM, Steven D'Aprano >>> wrote: >>>> Are you saying that the Egyptians, Babylonians and Greeks didn't >>>> know how to work with fractions? >>>> >>>> http://mathworld.wolfram.com/EgyptianFraction.html >>>> >>>> http://nrich.maths.org/2515 >>>> >>>> Okay, it's not quite 4000 years ago. Sometimes my historical sense >>>> of the distant past is a tad inaccurate. Shall we say 2000 years >>>> instead? >>> >>> Those links give dates of 1650 BC and 1800 BC respectively, so I'd >>> say your initial guess was closer. >> >> Right, but this is to miss the point. Let's say that 4000 years have >> defined 1/3 to be one third, but Python 3 (as do many programming >> languages) defines 1/3 to be something very very very very close to >> one third, and *that* idea is very very very very new! It's >> unfortunate that the example in this thread does not illustrate the >> main problem of shifting to binary floating point, because 1/2 >> happens to be exactly representable. > > I'm not going to dig back through the thread, but my recollection is > that's exactly why that example was chosen. Since 1/2 can be > represented exactly as a float, it *should* be represented as a float. > Picking another value (0) that isn't even close to the exact value of > 1/2 isn't helping anybody. Something else which I do not think has been stated yet in this thread is that floating point is an inexact representation. Just because integers and binary fractions have an exact correspondence we ought not to be affording them special significance. Floating point 1 is not the integer 1, it stands for a range of numbers some fraction either side of 1. There are other ways of handling non-integral numbers, such as fixed point, rational and unum. However current computing hardware is very much oriented to floating point, IEEE in particular. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: name for project of a cross version disassembler, and unmarshal program
Rustom Mody writes: > On Monday, May 23, 2016 at 1:38:41 PM UTC+5:30, rocky wrote: >> On Monday, May 23, 2016 at 2:17:07 AM UTC-4, Pete Forman wrote: >> > rocky writes: >> > >> > > I'm looking for a good name for a relatively new project I'll put >> > > on pypy. >> > > >> > > I've been working on a module to disassemble Python bytecode from >> > > many versions of Python. (Right now 2.3 .. 3.5 bytecode, largely >> > > works.) >> > > >> > > Of course, in order to do that you also need routines to >> > > unmarshal bytecode. So that's in there as well. >> > > >> > > In the future, I may could add a marshaler and an assembler to >> > > Python bytecode. I know, this is kind of perverse. >> > > >> > > At any rate the name I've been using is "pyxdis". See >> > > https://github.com/rocky/python-pyxdis. >> > > >> > > In the past I've been told by Polish-speaking people that my >> > > names are hard to pronounce. (If you've ever heard any Polish >> > > tongue twisters, you'll know that this really hurts.) >> > > >> > > Any suggestions for a better name? >> > >> > relipmoc >> > >> > -- >> > Pete Forman >> >> Interesting. (For those who are slow like myself, it is "compile" >> backwards. Well it's actually "compiler" but I'd not be offended if you want to develop the idea. > Heh! I also wondered... > And if you are into that kinda stuff, how about: ɔoɯdᴉlǝ ? (¿) I did consider suggesting that but it falls foul of PEP 426. PyPI is not yet ready to dip its toes outside of the confines of ASCII. [wry smile emoji deleted] -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: name for project of a cross version disassembler, and unmarshal program
rocky writes: > I'm looking for a good name for a relatively new project I'll put on pypy. > > I've been working on a module to disassemble Python bytecode from many > versions of Python. (Right now 2.3 .. 3.5 bytecode, largely works.) > > Of course, in order to do that you also need routines to unmarshal > bytecode. So that's in there as well. > > In the future, I may could add a marshaler and an assembler to Python > bytecode. I know, this is kind of perverse. > > At any rate the name I've been using is "pyxdis". See > https://github.com/rocky/python-pyxdis. > > In the past I've been told by Polish-speaking people that my names are > hard to pronounce. (If you've ever heard any Polish tongue twisters, > you'll know that this really hurts.) > > Any suggestions for a better name? relipmoc -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
Rustom Mody writes: > On Tuesday, April 19, 2016 at 6:49:34 AM UTC+5:30, sohcatoa wrote: >> On Monday, April 18, 2016 at 2:14:17 PM UTC-7, Pete Forman wrote: >> > Why is it that Python continues to use a fixed width font and therefore >> > specifies the maximum line width as a character count? >> > >> > An essential part of the language is indentation which ought to continue >> > to mandate that lines start with a multiple of 4 em worth of space (or >> > some other size or encode with hard tabs, that is not germane to my >> > question). The content of the line need not be bound by the rules needed >> > to position its start. >> > >> > -- >> > Pete Forman >> >> "Why is it that Python continues to use a fixed width font " >> >> This guy is trolling, right? No, it is a genuine question. It applies to computer langauges in general but this thread is about PEP 8 so I framed it for Python. I was not proposing a change to the langauge. > See elastic tabstops: http://nickgravgaard.com/elastic-tabstops/ I like that Nick separates out the concept of alignment with implicit semantics from the n spaces v tabs arguments. My question asks why monospace is used for the text. > And more generally that programmers sticking to text when rest of > world has moved on is rather backward: > http://blog.languager.org/2012/10/html-is-why-mess-in-programming-syntax.html -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
Ian Kelly writes: > On Mon, Apr 18, 2016 at 3:14 PM, Pete Forman wrote: >> Why is it that Python continues to use a fixed width font and >> therefore specifies the maximum line width as a character count? >> >> An essential part of the language is indentation which ought to >> continue to mandate that lines start with a multiple of 4 em worth of >> space (or some other size or encode with hard tabs, that is not >> germane to my question). The content of the line need not be bound by >> the rules needed to position its start. > > How many spaces is "4 em worth"? How would you incorporate that into > the Python compiler or a linter without needing to know what > particular font the programmer is using? What happens when another > programmer reviews the code using a different font and finds that > there is only 3.5em worth of space? Do we descend into Calibri / > Verdana line-length edit wars? 4 em is what PEP 8 implies, with the implicit use of a monospaced font. I was trying to convey that the mechanics of indentation was not relevant to my question about why Python and indeed other programming languages are rarely edited or viewed with proportional fonts. The programmer, other humans reading the source and the interpreter need to be able to discern structure by the indentation. It is what follows the indentation that interests me. The current Python interpreter will happily digest a combination of spaces and hard tabs as long as consistency rules are obeyed. My question was intended to concentrate on the presentation after the leading whitespace. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
Why is it that Python continues to use a fixed width font and therefore specifies the maximum line width as a character count? An essential part of the language is indentation which ought to continue to mandate that lines start with a multiple of 4 em worth of space (or some other size or encode with hard tabs, that is not germane to my question). The content of the line need not be bound by the rules needed to position its start. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Continuing indentation
Chris Angelico writes: > On Thu, Mar 3, 2016 at 10:46 AM, wrote: >> On Wednesday, March 2, 2016 at 3:44:07 PM UTC-5, Skip Montanaro wrote: >>> >>> if (some_condition and >>> some_other_condition and >>> some_final_condition): >>> play_bingo() >> >> How about: >> >> continue_playing = ( >> some_condition and >> some_other_condition and >> some_final_condition >> ) >> >> if continue_playing: >> play_bingo() >> >> or: >> >> play_conditions = [ >> some_condition, >> some_other_condition, >> some_final_condition, >> ] >> >> if all(play_conditions): >> play_bingo() > > Those feel like warping your code around the letter of the law, > without really improving anything. I beg to differ. If an expression is long or complex then splitting it up and, importantly, giving good names to the intermediates makes the code clearer. That advice is not restricted to if statements. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
Here's my Python sudoku solver which I wrote about 10 years ago. http://petef.22web.org/sudoku/ It works by applying the solving techniques I came up with. No trial and error or backtracking is used, so it is not up to cracking the very hardest puzzles. Run time is 15 ms to 45 ms on a 2009 MacBook Pro using Python 2.7.9. There are verbose options to print the steps. Sizes and multiple grids are flexible. IIRC it took a day or two to adapt the program when the first samurai was published. $ python sudoku.py -i sudoku2.sud ***|7**|*** 1**|***|*** ***|43*|2** ---+---+--- ***|***|**6 ***|5*9|*** ***|***|418 ---+---+--- ***|*81|*** **2|***|*5* *4*|***|3** Solved, rating: dead easy Calculation took 18.006 ms 264|715|839 137|892|645 598|436|271 ---+---+--- 423|178|596 816|549|723 759|623|418 ---+---+--- 375|281|964 982|364|157 641|957|382 -- Pete Forman http://petef.22web.org/payg.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Martijn Faassen: The Call of Python 2.8
Mark Lawrence writes: > On 14/04/2014 14:51, Marko Rauhamaa wrote: >> Chris Angelico : >> >>> If you're going to do that, why not just port your code to 3.x and >>> be done with it? Who has the resources to put hours and hours of dev >>> time into a 2.8? > > The people who haven't had enough time over the last eight years to > plan their upgrade path to 3.x. Eight years comes from the date of the > first message here https://mail.python.org/pipermail/python-3000/ > which was 21/03/2006, so feel free to come up with a different answer > for the time span. Would it help if we adopted a non-numeric name for this product to support eXisting Python for those who were notified some years ago that Python 2 would be superseded? How about Python XP? I thought not ;-) -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: pip3.x error using LIST instead of list
Dave Angel writes: > Mark Lawrence Wrote in message: >> >> >> No matter what I try I can't get the subcommands in lower-case when I >> have caps lock on, is there a simple work-around for this as well? :) >> > > You could do what I've done for my own DOS, Windows, and Linux > computers for years: > > disable the caps-lock key My solution on Windows is to turn on Toggle Keys in the Accessibility options. That beeps when the Caps Lock (or Num or Scroll) is pressed. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Using virtualenv to bypass sudoer issues
Jean-Michel Pichavant writes: > Thank you all for you insights. > > I'll probably go with virtualenv, I'll be able to distribute it among > the team. > There's still one point worrying me though: > We're doing a lot a remote execution. We're using "execnet" > http://codespeak.net/execnet/, and I'm not sure it can be compatible > with virtualenv. execnet working at the "python level" I don't see how > I can execute shell stuff before. > > I had a look at fabric http://docs.fabfile.org/en/1.8/, and it looks > like it can handle virtual env (anyone confirm?). > > Has someone already successfully remotely activated a venv then > execute a python scripts within that env, getting back the > stdout/stderr ? > > I'm afraid right now that switching to venv would mean switching from > execnet to fabric as well (I hate redoing stuff that works :-/ ). Call the venv version of python and activation is handled. E.g. in a fabfile myenv/bin/python myscript.py -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: pytz question: GMT vs. UTC
Grant Edwards writes: > On 2014-01-30, wxjmfa...@gmail.com wrote: > >> The temperature unit is the "Kelvin", not the "Degree Kelvin". >> One writes: 0 K, 275.15 K > > And remember to say "Kelvins" not "Kelvin" when speaking about > temperatures other than 1 K. And remember to write kelvins. SI units named after people such as kelvin, watt and pascal are lower case while their symbols have a leading capital: K, W, Pa. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Guessing the encoding from a BOM
Chris Angelico writes: > On Fri, Jan 17, 2014 at 8:10 PM, Mark Lawrence > wrote: >> Slight aside, any chance of changing the subject of this thread, or even >> ending the thread completely? Why? Every time I see it I picture Inspector >> Clouseau, "A BOM!!!" :) > > Special delivery, a berm! Were you expecting one? Endian detection: Does my BOM look big in this? -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Guessing the encoding from a BOM
Rustom Mody writes: > On Friday, January 17, 2014 7:10:05 AM UTC+5:30, Tim Chase wrote: >> On 2014-01-17 11:14, Chris Angelico wrote: >> > UTF-8 specifies the byte order >> > as part of the protocol, so you don't need to mark it. > >> You don't need to mark it when writing, but some idiots use it >> anyway. If you're sniffing a file for purposes of reading, you need >> to look for it and remove it from the actual data that gets returned >> from the file--otherwise, your data can see it as corruption. I end >> up with lots of CSV files from customers who have polluted it with >> Notepad or had Excel insert some UTF-8 BOM when exporting. This >> means my first column-name gets the BOM prefixed onto it when the >> file is passed to csv.DictReader, grr. > > And its part of the standard: > Table 2.4 here > http://www.unicode.org/versions/Unicode5.0.0/ch02.pdf It would have been nice if there was an eighth encoding scheme defined there UTF-8NB which would be UTF-8 with BOM not allowed. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Encoding of surrogate code points to UTF-8
Steven D'Aprano writes:
> I think this is a bug in Python's UTF-8 handling, but I'm not sure.
[snip]
> py> s = '\ud800\udc01'
> py> s.encode('utf-8')
> Traceback (most recent call last):
> File "", line 1, in
> UnicodeEncodeError: 'utf-8' codec can't encode character '\ud800' in
> position 0: surrogates not allowed
>
>
> Have I misunderstood? I think that Python is being too strict about
> rejecting surrogate code points. It should only reject lone surrogates,
> or invalid pairs, not valid pairs. Have I misunderstood the Unicode FAQs,
> or is this a bug in Python's handling of UTF-8?
http://www.unicode.org/versions/Unicode6.2.0/ch03.pdf
D75 Surrogate pair: A representation for a single abstract character
that consists of a sequence of two 16-bit code units, where the first
value of the pair is a high-surrogate code unit and the second value
is a low-surrogate code unit.
* Surrogate pairs are used only in UTF-16. (See Section 3.9, Unicode
EncodingForms.)
* Isolated surrogate code units have no interpretation on their own.
Certain other isolated code units in other encoding forms also have no
interpretation on their own. For example, the isolated byte [\x80] has
no interpretation in UTF-8; it can be used only as part of a multibyte
sequence. (See Table 3-7). It could be argued that this line by itself
should raise an error.
That first bullet indicates that it is indeed illegal to use surrogate
pairs in UTF-8 or UTF-32.
--
Pete Forman
--
https://mail.python.org/mailman/listinfo/python-list
Re: PyQt5 and virtualenv problem
"D. Xenakis" writes: > I tried to install SIP and PyQt5 using the pip install command but it > didnt work on both cases (i was getting errors), so i finally > installed them using the windows installers provided in > riverbankcomputing website. > My problem though here is that whenever i try to create a new > virtualenv enviroment, those packages are not included and i cant > import them. How can i add PyQt5 to my new virt enviroment? What is > the logic behind this problem so i understand whats going on here? > > Thx in advance I can't comment on PyQt5 but I can say how to use PyQt4 with virtualenv on Windows. The Riverbank installers do not work in a virtualenv. However PySide wraps PyQt4 in a compatible installer. To use the installer it should be invoked with easy_install rather than pip install. Having installed it, pip uninstall works. https://pypi.python.org/pypi/PySide The Riverbank installer can install PyQt5 to your master copy of Python. You can then use the --system-site-packages flag when creating a virtualenv. The default behavior of virtualenv changed in 1.7 (2011-11-30) from including system packages to excluding them. -- Pete Forman -- http://mail.python.org/mailman/listinfo/python-list
Re: Popen and reading stdout in windows
"Joseph L. Casale" writes: >> You leave out an awful amount of detail. I have no idea what ST is, >> so I'll have to guess your real problem. > > Ugh, sorry guys its been one of those days, the post was rather > useless... > > I am using Popen to run the exe with communicate() and I have sent > stdout to PIPE without luck. Just not sure what is the proper way to > iterate over the stdout as it eventually makes its way from the > buffer. You could try Sarge which is a wrapper for subprocess providing command pipeline functionality. http://sarge.readthedocs.org/ -- Pete Forman -- http://mail.python.org/mailman/listinfo/python-list
Re: LBYL vs EAFP
Steven D'Aprano writes: >> I want to check that a value is a number. [...] > I'm leaning towards an isinstance check Well that is the answer to your question, whether the value *is* a number. EAFP can answer the question whether the value *behaves* like a number, where the criterion depends on what your code is aiming to do with the value. BTW what if the value is Not-a-Number? ;-) -- Pete Forman -- http://mail.python.org/mailman/listinfo/python-list
Re: PIL or something to open EXIF Metadata with Python
Tim Golden writes: > On 09/01/2013 14:45, Jose Trevino wrote: >> I am trying to load the PIL module to manage exif metadata with >> Python but have had no success. > > > Try pyexiv2: > > http://tilloy.net/dev/pyexiv2/ > > TJG Or Hachoir http://pypi.python.org/pypi/hachoir-metadata https://bitbucket.org/haypo/hachoir/wiki/Home -- Pete Forman -- http://mail.python.org/mailman/listinfo/python-list
Re: Parsing ISO date/time strings - where did the parser go?
John Nagle writes: >I want to parse standard ISO date/time strings such as > > 2012-09-09T18:00:00-07:00 > > into Python "datetime" objects. Consider whether RFC 3339 might be a more suitable format. It is a subset of ISO 8601 extended format. Some of the restrictions are Year must be 4 digits Fraction separator is period, not comma All components including time-offset are mandatory, except for time-secfrac time-minute in time-offset is not optional, must use ±hh:mm or Z Some latitude is allowed T may be replaced by e.g. space Extra feature time-offset of -00:00 means UTC but local time is unknown -- Pete Forman -- http://mail.python.org/mailman/listinfo/python-list
Re: if, continuation and indentation
HH writes: > I have a question about best practices when it comes to line > wrapping/ continuation and indentation, specifically in the case of > an if statement. There are several good suggestions for formatting but no-one has mentioned rewriting the code. Use a boolean variable to hold the result of the condition and then the if statement is more readable. -- Pete Forman-./\.- West Sussex, UK -./\.- http://petef.22web.net -./\.- petef4+use...@gmail.com -./\.- -- http://mail.python.org/mailman/listinfo/python-list
Re: xmlrpc slow in windows 7 if hostnames are used
"Gabriel Genellina" writes: > En Sat, 06 Feb 2010 22:15:48 -0300, Jean-Michel Pichavant > escribió: > >> I'm puzzled. >> Unless my english is failing me, everything would be solved using >> hostnames if I follow you. Why don't you do that ? >> I am no network/IP guru, but it sounds very weird to have requests >> rejected when using IP addresses. Are you sure your host names are >> resolved with the same IPM address you are using ? > > HTTP 1.1 requires a Host: header field; this way, multiple web > servers may share the same IP address. So you can't identify a host > by its IP alone; the host name is required. This was devised in > order to save IPv4 addresses; LACNIC (the Latin America addresses > register) does not assign addresses to ISP's based solely on web > hosting anymore - they MUST share existing IPs. And I think a > similar policy is used on other regions. If you really want to go for speed you should be able to set the Host: header to the name but use the IP address to make the connection. Something else that might be slowing you down is anti-spyware or anti-virus. Several products put a long list of blacklist sites in the hosts file. Windows can be rather slow to process that file. -- Pete Forman-./\.- West Sussex, UK -./\.- http://petef.22web.net -./\.- petef4+use...@gmail.com -./\.- -- http://mail.python.org/mailman/listinfo/python-list
Re: optparse versus getopt
Robert Kern writes: >> is there some way i can force the import based on the the absolute >> path to the module? > > Better would be for you to copy the optparse.py module onto your > Jython's import path. I'm not particularly familiar with the details > of Jython, so you will need to consult with the Jython documentation > unless if a Jython expert can jump in here. Here is one message > describing this procedure: > > http://osdir.com/ml/lang.jython.user/2004-01/msg00086.html Here are notes from some of my code which can run on Jython. You might also like to check out Jython 2.5 which is in beta. Jython 2.2 needs optparse.py and textwrap.py. These can be copied from Python 2.3 or Optik 1.4.1 or later. May also need gettext.py and locale.py. -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent pete.for...@westerngeco.com-./\.- the opinion of Schlumberger or http://petef.22web.net -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter w.pack()?
"W. eWatson" writes: > MRAB wrote: >> W. eWatson wrote: > ... >>> I thought some months ago, I found Google commands that would >>> operate in the browser link window. Guess not. >>> >>> BTW, isn't there an O'Reilly book on Google hacks of this sort? >>> Where else does one find out about these Google tools? >>> >> Google? :-) >> http://www.google.com/support/websearch/bin/answer.py?hl=en&answer=136861 >> > Thanks. I may have that book marked from many, many months ago. If so, > I see why I'd never find it. The BM entry does not show "Google". It > does now. ;-) As well as the site: modifier check out inurl: and friends. http://www.google.com/help/operators.html -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent pete.for...@westerngeco.com-./\.- the opinion of Schlumberger or http://petef.22web.net -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Re: alt.possessive.its.has.no.apostrophe
Aaron Brady writes: > On Dec 15, 11:04 am, Steve Holden wrote: >> Tim Chase wrote: >> > Steve Holden wrote: >> >> This led to a schism between the British and the >> >> newly-independent Americans, who responded by taking the "u" >> >> out of colour, valour, and aluminium. >> >> > Darn Americans and their alminim ;-) >> >> > Next thing you know, they'll be putting an I in TEAM.[1] >> >> It's called humour. Or humor. Or incompetence ;-) > > There's an 'I' in Python. There's no 'F' in Python in this thread. -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent pete.for...@westerngeco.com-./\.- the opinion of Schlumberger or http://petef.22web.net -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Re: alt.possessive.its.has.no.apostrophe
Steve Holden writes: > Ben Finney wrote: >> James Stroud writes: >> >>> Ben Finney wrote: >>>> James Stroud writes: >>>> >>>>> Yes. I think it was the British who decided that the apostrophe >>>>> rule for "it" would be reversed from normal usage relative to >>>>> just about every other noun. >> >> It also seems an indefensible claim to say that anyone "decided" it >> would be that way, especially "the British". >> > It's our language, dammit! Ours, ours, ours! > > This decision was actually taken at a meeting of the Society of > British pedants on November 23, 1786. This led to a schism between > the British and the newly-independent Americans, who responded by > taking the "u" out of colour, valour, and aluminium. I'd thought that the main schism was triggered by a tax on tea but it turns out that it was due to an apostrophe after t. ;-) -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent pete.for...@westerngeco.com-./\.- the opinion of Schlumberger or http://petef.22web.net -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Re: int() and leading zeros in Python 2.6
Peter Otten <[EMAIL PROTECTED]> writes: > you're wrong. Indeed I am, sorry for the waste of time. -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or http://petef.22web.net -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
int() and leading zeros in Python 2.6
I'm holding off installing Python 2.6, waiting for some packages to
become available for it. I wonder if someone could tell me the best
way to avoid future problems parsing decimal integers with leading
zeros.
>>> int('09')
9
That works in 2.5 but will break in 2.6 AFAIK as int() is being
changed to use Numeric Literal syntax. It will give a syntax error as
the leading 0 will force an octal radix and the 9 will be out of
range. Will this avoid the breakage?
>>> int('09', 10)
9
Or should I use this uglier variation that needs 2.2.2 or later?
>>> int('09'.lstrip('0'))
9
Is the documentation for int([x[, radix]]) correct? I'd say that the
default for radix has become 0.
http://docs.python.org/library/functions.html#int
--
Pete Forman-./\.- Disclaimer: This post is originated
WesternGeco -./\.- by myself and does not represent
[EMAIL PROTECTED]-./\.- the opinion of Schlumberger or
http://petef.22web.net -./\.- WesternGeco.
--
http://mail.python.org/mailman/listinfo/python-list
Re: docpicture
Scott David Daniels <[EMAIL PROTECTED]> writes: > or you could even use: > ''' > 1234567890ABCDEF... > ''' > A comment _not_ a docstring (only found by scanning the source). > which is easy enough to hunt for. -1 for XML based syntax, we should instead look to reST. It already has image and figure directives. The docs say that image takes a URI argument and some options. So an external file should work now. Maybe someone would like to play with the data URL scheme (RFC 2397) to meet the OP's desire to embed the image. AFAIK a downside is that MS are only starting to support that in IE8. -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or http://petef.22web.net -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Re: python syntax for conditional is unfortunate
Asun Friere <[EMAIL PROTECTED]> writes:
> A canonical use of the conditional operator is in
> pluralising words, (eg. '%s dollar' % n + 's' if n!=1 else '').
That fails for n == 1. So what is best?
for i in range(4):
print '%d thing' % i + ('s' if i != 1 else '')
for i in range(4):
print '%d thing%s' % (i, ('s', '')[i==1])
for i in range(4):
print '%d thing%s' % (i, 's' if i != 1 else '')
--
Pete Forman-./\.- Disclaimer: This post is originated
WesternGeco -./\.- by myself and does not represent
[EMAIL PROTECTED]-./\.- the opinion of Schlumberger or
http://petef.22web.net -./\.- WesternGeco.
--
http://mail.python.org/mailman/listinfo/python-list
Re: PEP proposal optparse
James <[EMAIL PROTECTED]> writes:
> I would like to know your thoughts on a proposed change to optparse
> that I have planned. It is possible to add default values to
> multiple options using the set_defaults. However, when adding
> descriptions to options the developer has to specify it in each
> add_option() call.
-1
I see no advantage to swelling optparse when the language offers many
solutions already. E.g.
desc = {
'verbose': 'Output less information',
'castordir': 'specify the wanted CASTOR directory where to store '
'the results tarball',
'previousrel': 'Top level dir of previous release for regression '
'analysis'}
parser.add_option('-q', '--quiet', action="store_false",
dest='verbose', help = desc['verbose'])
...
Or another approach might be like this.
for ... in zip(...):
parser.add_option(...)
--
Pete Forman-./\.- Disclaimer: This post is originated
WesternGeco -./\.- by myself and does not represent
[EMAIL PROTECTED]-./\.- the opinion of Schlumberger or
http://petef.22web.net -./\.- WesternGeco.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python-URL! - weekly Python news and links (Sep 9)
"Gabriel Genellina" <[EMAIL PROTECTED]> writes: > QOTW: "So why am I supposed to care about SOAP again? Oh yes, the > wizards I can use to generate 'web service end-points' from > programming language code. My years in the SOAP trenches just > makes me laugh myself half to death at that notion: I would > probably have been twice as productive if every time I reached for > a SOAP toolkit I instead just coded straight XML in HTTP. And this > represents experience with Python, Java and C WS tools." - Uche > Ogbuji It looks as if that Large Hadron Collider is having ill effects already. A week has been stretched into 6 years. ;-) http://lists.xml.org/archives/xml-dev/200302/msg00259.html -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or http://petef.22web.net -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Re: code of a function
alex23 <[EMAIL PROTECTED]> writes: > Which is very handy, like most of IPython. +1 QOTW -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or http://petef.22web.net -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Re: Am I missing something with Python not having interfaces?
I would suggest that using an interface at compile time is not the only approach. Unit tests can be run on classes to check that they do indeed quack. -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or http://petef.22web.net -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Re: best way to have enum-like identifiers?
[EMAIL PROTECTED] writes: > Currently I'm just putting this at the top of the file: > > py=1 > funcpre=2 > funcpost=3 > ... That can be done more compactly with py, funcpre, funcpost = range(3) give or take 1. > but I'm curious if there's a better way of doing this, > some kind of enum-like thing or somesuch. https://launchpad.net/munepy describes itself as yet another Python enum implementation. Its author is Barry Warsaw. -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or http://petef.22web.net -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Re: Will Python on day replace MATLAB?????????????????????????????????????????????????????
Jaap Spies <[EMAIL PROTECTED]> writes: > Have a look at Sage: http://www.sagemath.org/ Of relevance to SciPy is the following http://wiki.sagemath.org/days8 | The Sage_ and Scipy_ teams and `Enthought Inc.`_ are pleased to | announce the first collaborative meeting for Sage/Scipy joint | development, to be held from February 29 until March 4, 2008 at the | Enthought headquarters in Austin, Texas. | | The purpose of this meeting is to gather developers for these | projects in a friendly atmosphere for a few days of technical talks | and active development work. It should be clear to those | interested in attending that this is *not* an academic conference, | but instead an opportunity for the two teams to find common points | for collaboration, joint work, better integration between the | projects and future directions. The focus of the workshop will be | to actually *implement* such ideas, not just to plan for them. -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or http://petef.port5.com -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Standardization: Wikipedia entry
Paul Boddie <[EMAIL PROTECTED]> writes: > Yes, you don't really want standardisation ANSI/ISO-style as the > standards themselves are not freely distributable Some ISO standards have been made available for free. Copyright terms apply. Over 300 are listed here: http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or http://petef.port5.com -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Re: When is min(a, b) != min(b, a)?
Mark Dickinson <[EMAIL PROTECTED]> writes: > Any change to Python that made == and != checks involving NaNs raise > an exception would have to consider the consequences for set, dict, > list membership testing. > > > and if Python had separate operators for these two purposes it > wouldn't be Python any more. There are separate Python operators, "==" and "is". The C99 standard, which Python defers to for its implementation, says in 6.2.6.1.4: Two values (other than NaNs) with the same object representation compare equal, but values that compare equal may have different object representations. In 7.12.13, the fmax and fmin functions treat NaNs as missing arguments. Most other operations return NaN if an argument is NaN, or for a domain error. 7.12.14 specifies comparison macros that are quiet versions of the relational operators. BTW floating-point exceptions in C and IEEE are not the same as exceptions in higher level languages. The behavior of signalling NaNs are not defined in C. Only quiet NaNs are returned from operations. An invalid floating-point exception may well just set a status flag. That may be tested after a set of calculations. With pipelining the exact cause of the exception will be unknown. -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or http://petef.port5.com -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Re: When is min(a, b) != min(b, a)?
Christian Heimes <[EMAIL PROTECTED]> writes: > Antoon Pardon wrote: >> That doesn't follow. The problem is not that x < nan returns False >> because that is correct since x isn't smaller than nan. The problem >> is cmp(x, nan) returning 1, because that indicates that x is greater >> than nan and that isn't true. > > Please report the problem. cmp(), min() and max() don't treat NaNs > right. I don't think that x < nan == False is the correct answer, too. > But I've to check the IEEE 754 specs. IMHO < nan and > nan should raise > an exception. I disagree with your last sentence. We are dealing with quiet NaNs which should not raise exceptions. x < nan is well defined in IEEE, it is false. IMHO cmp() should raise an exception if one or more arguments is a NaN. Its current definition is to return an integer which may be negative, zero, or positive for less than, equal, or greater than. There is no spec for unordered, and the integer returned cannot be NaN. I'd be happy if min() and max() behaved as if their comparison operations were minNum and maxNum from IEEE. In other words they never return NaN unless all their arguments are NaN. int(nan) should raise an exception. I note that in Python 2.5.1 int(inf) already does. -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or http://petef.port5.com -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Re: When is min(a, b) != min(b, a)?
Grant Edwards <[EMAIL PROTECTED]> writes: > For applications I work on, it should be NaN. But I think the > result of comparing a Normal to a NaN is undefined, so the > above behavior is allowed by the IEEE spec. Comparison of two floating point datums results in exactly one of these being true: 1) less than 2) equal 3) greater than 4) unordered IEEE 754r defines maxNum and minNum which are explicitly defined to return one argument if the other is a NaN. Any other operation (apart from a few others that are specified) return a NaN if any argument is NaN. NaN generally represents the result of an invalid operation. Using it for missing value is not in the draft standard, though it is not forbidden either. If NaNs in your data are important then you must take care in explicit and implicit comparisons to consider unordered results. -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or http://petef.port5.com -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Re: SimplePrograms challenge
Steve Howell <[EMAIL PROTECTED]> writes: > The BankAccount example is about as small of a "complete" class > example that I could come up with, even though it's "complete" only > a basic level. It would be good to have a larger class example > that fleshes out the concept a bit more, even if it's just > BankAccount revisited. I have some free time next time, I'll try > my hand at it. I guess I didn't put enough smilies in my post. Your example is simple and small which is correct for the context of the SimplePrograms page. Classes should precede unittest as the latter uses a new style class. Perhaps the thing to do is to add links to the tutorial for those seeking further enlightenment. If your page gets much bigger it will lose its original attraction. -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or http://petef.port5.com -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Re: SimplePrograms challenge
Steve Howell <[EMAIL PROTECTED]> writes: >3) The median example raises the question of what > would happen with an empty list. I don't think it's > important to cover that case in the simple example > (it's really the responsibility of the caller IMO not > to call median with nonsense arguments), but perhaps > there is a simple way to fix this? An empty list raises an IndexError, a non-iterable raises TypeError. This is correct behavior IMHO, there is nothing to fix. Median should return an element (or average of two) from its input and if that is not meaningful returning None or other special value is neither appropriate nor Pythonic. Only the caller knows how to handle such exceptional circumstances. Actually there are some other issues. Should the median of an even number of integers allow halves? Should median insist that its input has an odd number of elements? But it's tough squeezing all that discourse into 13 or 14 lines ;-) BankAccount allows arbitrarily large withdrawals, is that to be fixed too? -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or http://petef.port5.com -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Re: SimplePrograms challenge
Steve Howell <[EMAIL PROTECTED]> writes: > Feel free to change the page as you see fit, although thanks for > discussing it here first. Done. I've moved classes up as unittest depends on it. The changes that I made to classes were: 1) Use new style class. 2) Demonstrate Pythonic use of attribute (no get/set). 3) Pare some lines. -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or http://petef.port5.com -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Re: SimplePrograms challenge
Steve Howell <[EMAIL PROTECTED]> writes: >> 2) assert is not the simplest example of doctest. >> The style should be >> >> >>> add_money([0.13, 0.02]) >> 0.15 >> >>> add_money([100.01, 99.99]) >> 200.0 >> >>> add_money([0, -13.00, 13.00]) >> 0.0 >> > > That's not clear cut to me. I think vertical > conciseness has an advantage for readability, as it > means you get to keep more "real" code on the screen. What I meant was that doctest should be "type this into the interpreter and you should see that". A doctest is not a unit test, though it may form a subset of the tests. There should only be enough doctests to enclue a human reader. Comprehensive testing should use a larger framework. Doctests in separate files can do this but I would use py.test, or alternatives like nose or Testoob. >>> 2 + 2 4 "assert 2 + 2 == 4" is a concise way of writing a unit test but it is not the best way to use doctest IMHO. >> 3) which fails :-( So both the unittest and doctest >> examples ought to >>be redone to emphasize what they are doing >> without getting bogged >>down by issues of floating point representations. >> > > I was the one who originally posted the floating point > example (with yet another style of unit testing, BTW), > and I agree that the subtleties of floating point do > kind of cloud the issue. I welcome a better example. > What I didn't realize is that there's an actual error. > Are you saying the program fails? On which test? Python 2.5.1 on XP: Failed example: add_money([0.13, 0.02]) Expected: 0.15 Got: 0.14999 -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or http://petef.port5.com -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Re: SimplePrograms challenge
André <[EMAIL PROTECTED]> writes: > Ok, doctest-based version of the Unit test example added; so much > more Pythonic ;-) Sorry for being a bit picky but there are a number of things that I'm unhappy with in that example. 1) It's the second example with 13 lines. Though I suppose that the pragmatism of pairing the examples overriding an implicit goal of the page is itself Pythonic. 2) assert is not the simplest example of doctest. The style should be >>> add_money([0.13, 0.02]) 0.15 >>> add_money([100.01, 99.99]) 200.0 >>> add_money([0, -13.00, 13.00]) 0.0 3) which fails :-( So both the unittest and doctest examples ought to be redone to emphasize what they are doing without getting bogged down by issues of floating point representations. http://wiki.python.org/moin/SimplePrograms -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or http://petef.port5.com -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's handling of unicode surrogates
Ross Ridge <[EMAIL PROTECTED]> writes: > The Unicode standard doesn't require that you support surrogates, > or any other kind of character, so no you wouldn't be lying. +1 on Ross Ridge's contributions to this thread. If Unicode is processed using UTF-8 or UTF-32 encoding forms then there are no surrogates. They would only be present in UTF-16. CESU-8 is strongly discouraged. A Unicode 16-bit string is allowed to be ill-formed as UTF-16. The example they give is one string that ends with a high surrogate code point and another that starts with a low surrogate code point. The result of concatenation is a valid UTF-16 string. The above refers to the Unicode standard. In Python with narrow Py_UNICODE a unicode string is a sequence of 16-bit Unicode code points. It is up to the programmer whether they want to specially handle code points for surrogates. Operations based on concatenation will conform to Unicode, whether or not there are surrogates in the strings. -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or http://petef.port5.com -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Re: matplotlib basic question
Robert Kern <[EMAIL PROTECTED]> writes: > Colin J. Williams wrote: > >> I'm not sure that scipy has been updated to Python 2.5 > > ? scipy certainly works with 2.5. Are you referring to something > else perhaps? Yes, the Python Enthought Edition was being discussed and it is currently based on Python 2.4.3. http://code.enthought.com/enthon/ -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or http://petef.port5.com -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Re: matplotlib basic question
orangeDinosaur <[EMAIL PROTECTED]> writes: > [...] But now, the figure window is completely unresponsive -- I > can't even close it without getting the "your program is not > repsonding" business. What am I missing? This behavior so far > seems pretty unintuitive. The best way out of this is to use IPython. It also needs a backend which remains responsive, WxAgg works but Tk did not last time I tried. IPython 0.8.1 is a release candidate which fixes some Windows issues in 0.8.0. If you want a stable package that has all the parts present out of the box then look at Enthought. -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or http://petef.port5.com -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Windows upgrade incomplete
I've a few versions of Python on my XP PC, most recently Python 2.5. The file associations appear not to have been upgraded. Executing a .py file turned out to still be using 2.3. >assoc .py .py=Python.File >ftype Python.file Python.file=D:\PROGRA~1\Python23\python.exe "%1" %* Presumably if I'd uninstalled the old Python first I'd have not seen this. I've amended my file type associations and all is now well. Someone might care to look at the installer. I've used the MSIs since 2.4. -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or http://petef.port5.com -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Re: Coding style and else statements
Ben Finney <[EMAIL PROTECTED]> writes: > Why not ensure that there is one return point from the function, so > the reader doesn't have to remind themselves to look for hidden > return points? There will always be more potential return points in languages that support exceptions. -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or http://petef.port5.com -./\.- WesternGeco. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to measure execution time of a program
"Fredrik Lundh" <[EMAIL PROTECTED]> writes: > simplest way: > > t0 = time.time() You can get better resolution by using time.clock() instead of time.time(). -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- opinion of Schlumberger, Baker http://petef.port5.com -./\.- Hughes or their divisions. Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php -- http://mail.python.org/mailman/listinfo/python-list
Ovum quote about Python
In an article about the Royal Bank of Scotland working with Zope there is this quote from Gary Barnett, a research director at analyst firm Ovum: "A lot of banks are using applications like Apache and Perl, but it's interesting to see they're using Python and Zope as it's moderately hardcore open source stuff". http://news.zdnet.co.uk/software/applications/0,39020384,39248923,00.htm -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- opinion of Schlumberger, Baker http://petef.port5.com -./\.- Hughes or their divisions. -- http://mail.python.org/mailman/listinfo/python-list
Re: zipfile and file permissions
Robert Kern <[EMAIL PROTECTED]> writes: > Pete Forman wrote: >> I'm trying to move the building of a zip file from a shell script into >> python. It is mostly working but when I unzip the files the UNIX >> permissions are not preserved. The zip program I've been using is the >> standard(?) one on Linux, from Info-Zip. Presumably I need to do >> something with external_attr in ZipInfo, any pointers? > > C.f.: http://mail.python.org/pipermail/pythonmac-sig/2005-March/013491.html Thanks. I've put a work around in my code to set create_system. I've also made a patch for zipfile.py which I'm trying to submit to sourceforge. No luck so far, I'll try again later. Recently I submitted a patch to the python-mode project, so I think I'm following the correct procedure. -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- opinion of Schlumberger, Baker http://petef.port5.com -./\.- Hughes or their divisions. -- http://mail.python.org/mailman/listinfo/python-list
zipfile and file permissions
I'm trying to move the building of a zip file from a shell script into python. It is mostly working but when I unzip the files the UNIX permissions are not preserved. The zip program I've been using is the standard(?) one on Linux, from Info-Zip. Presumably I need to do something with external_attr in ZipInfo, any pointers? -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- opinion of Schlumberger, Baker http://petef.port5.com -./\.- Hughes or their divisions. -- http://mail.python.org/mailman/listinfo/python-list
Re: injecting "set" into 2.3's builtins?
Skip Montanaro <[EMAIL PROTECTED]> writes: > Stephen> I have: > Stephen> try: > Stephen> set > Stephen> except NameError: > Stephen> from sets import Set as set > > Stephen> in my code in a few places. > > Yes, but then pychecker complains about a statement with no apparent effect, > hence the extra verbiage. > > My question wasn't about a less ugly way to type what I type now. It was > about whether injecting "set" into the builtins (so I can dispense with the > above cruft altogether) is likely to cause problems. I think not, certainly > based on what little surveying I've done at work. I was hoping someone else > had already tried this and could report on their experience. This is what I use to allow my 2.4 code to run on 2.3. if not 'set' in dir(__builtins__): from sets import Set as set, ImmutableSet as frozenset -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- opinion of Schlumberger, Baker http://petef.port5.com -./\.- Hughes or their divisions. -- http://mail.python.org/mailman/listinfo/python-list
