Adding PEP 495 support to dateutil
On Sat, Sep 12, 2015 at 9:58 PM, Tim Peters wrote: > I think acceptance of 495 should be contingent upon > someone first completing a fully functional (if not releasable) > fold-aware zoneinfo wrapping. > After studying both pytz and dateutil offerings, I decided that it is easier to add "fold-awareness" to the later. I created a fork [1] on Github and added [2] fold-awareness logic to the tzrange class that appears to be the base class for most other tzinfo implementations. I was surprised how few test cases had to be changed. It looks like dateutil test suit does not test questionable (in the absence of fold) behavior. I will need to beef up the test coverage. I am making all development public early on and hope to see code reviews and pull requests from interested parties. Pull requests with additional test cases are most welcome. [1]: https://github.com/abalkin/dateutil/tree/pep-0495 [2]: https://github.com/abalkin/dateutil/commit/57ecdbf481de7e21335ece8fcc5673d59252ec3f -- https://mail.python.org/mailman/listinfo/python-list
broken install?
Hi there! I just downloaded 3.5.0 install package for Win32 (python-3.5.0-webinstall.exe) and I see some strange behaviour under Win XP: there is no "Next" or "Run" button in wizard ))) Clicked into space near "Cancel" I opened "options" screen, while clicked in another place (closer to center of window) setup started without any options at all ))) Screen is attached below -- Best Regards Serj -- https://mail.python.org/mailman/listinfo/python-list
Re: broken install?
On 15/09/2015 11:43, Serj wrote: > Hi there! > > I just downloaded 3.5.0 install package for Win32 > (python-3.5.0-webinstall.exe) and I see some strange behaviour under Win > XP: there is no "Next" or "Run" button in wizard ))) > > Clicked into space near "Cancel" I opened "options" screen, while > clicked in another place (closer to center of window) setup started > without any options at all ))) Python has dropped support for Windows XP: https://docs.python.org/3.5/whatsnew/3.5.html#unsupported-operating-systems TJG -- https://mail.python.org/mailman/listinfo/python-list
Re: broken install?
On Tue, Sep 15, 2015 at 8:43 PM, Serj wrote: > I just downloaded 3.5.0 install package for Win32 > (python-3.5.0-webinstall.exe) and I see some strange behaviour under Win > XP: there is no "Next" or "Run" button in wizard ))) Python 3.5 no longer supports Windows XP, sorry. You can continue to use Python 3.4, or you can upgrade to a newer operating system (Windows 7... or Debian Linux "Jessie" :) ), but CPython 3.5 uses functionality that Windows XP simply doesn't offer. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
Emile van Sebille wrote: Shroedingers-cat-was-just-a-cat-in-a-box-too-ly y'rs, The real question is, if you kill Schroedinger's cat, does Heisenberg's cat die too? If so, then either they're the same cat, or they're two entangled cats. This suggests an alternative model for Python computation. All data is represented by cats. A variable is a box containing a cat. Assignment replaces one cat with an entangled copy of another cat, so that mutating either one affects the other. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Wed, Sep 16, 2015 at 6:14 PM, Gregory Ewing wrote: > Emile van Sebille wrote: > >> Shroedingers-cat-was-just-a-cat-in-a-box-too-ly y'rs, > > > The real question is, if you kill Schroedinger's cat, does > Heisenberg's cat die too? If so, then either they're the > same cat, or they're two entangled cats. > > This suggests an alternative model for Python computation. > All data is represented by cats. A variable is a box > containing a cat. Assignment replaces one cat with an > entangled copy of another cat, so that mutating either > one affects the other. Quantum computing is the way of the future! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
Chris Angelico writes: > On Wed, Sep 16, 2015 at 6:14 PM, Gregory Ewing > wrote: > > This suggests an alternative model for Python computation. All data > > is represented by cats. A variable is a box containing a cat. > > Assignment replaces one cat with an entangled copy of another cat, > > so that mutating either one affects the other. > > Quantum computing is the way of the future! Tachyon computing is the way of the future *and* the past. -- \ “[Entrenched media corporations will] maintain the status quo, | `\ or die trying. Either is better than actually WORKING for a | _o__) living.” —ringsnake.livejournal.com, 2007-11-12 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
ANN: PyDDF Python Sprint 2015
[This announcement is in German since it targets a Python sprint in Düsseldorf, Germany] ANKÜNDIGUNG PyDDF Python Sprint 2015 in Düsseldorf Samstag, 26.09.2015, 10:00-18:00 Uhr Sonntag, 27.09.2015, 10:00-18:00 Uhr trivago GmbH, Karl-Arnold-Platz 1A, 40474 Düsseldorf 4. Stock, Raum 25 "Madrid" Python Meeting Düsseldorf http://pyddf.de/sprint2015/ INFORMATION Das Python Meeting Düsseldorf (PyDDF) veranstaltet mit freundlicher Unterstützung der *trivago GmbH* ein Python Sprint Wochenende im September. Der Sprint findet am Wochenende 26/27.09.2015 im 4. Stock der trivago Niederlassung am Karl-Arnold-Platz 1A statt (nicht am Bennigsen-Platz 1). Bitte beim Pförtner melden. Google Maps: https://www.google.de/maps/dir/51.2452741,6.7711581//@51.2450432,6.7714612,18.17z?hl=de Folgende Themengebiete haben wir als Anregung angedacht: * Openpyxl Openpyxl ist eine Python Bibliothek, mit der man Excel 2010 Dateien lesen und schreiben kann. Charlie ist Co-Maintainer des Pakets. * Python 3 Portierung von mxDateTime mxDateTime ist ein Python Bibliothek für Datums- und Zeitgrößen, die früher der Standard für solche Datentypen war, bevor das datetime Modul zu Python hinzukam. Die Bibliothek wird von einer ganzen Reihe Projekten verwendet und soll auf Python 3 portiert werden. Marc-Andre hat mxDateTime geschrieben. Für die Portierung sind Kenntnisse in Python 2.7, 3.4 und ANSI C von Vorteil. Fehlende Kenntnisse können aber natürlich schnell erlernt werden. Natürlich kann jeder Teilnehmer weitere Themen vorschlagen, z.B. * Kivy * Raspberry Pi * FritzConnection * OpenCV * u.a. Alles weitere und die Anmeldung findet Ihr auf der Sprint Seite: http://pyddf.de/sprint2015/ Teilnehmer sollten sich zudem auf der PyDDF Liste anmelden, da wir uns dort koordinieren: https://www.egenix.com/mailman/listinfo/pyddf ÜBER UNS Das Python Meeting Düsseldorf (PyDDF) ist eine regelmäßige Veranstaltung in Düsseldorf, die sich an Python Begeisterte aus der Region wendet: * http://pyddf.de/ Einen guten Überblick über die Vorträge bietet unser YouTube-Kanal, auf dem wir die Vorträge nach den Meetings veröffentlichen: * http://www.youtube.com/pyddf/ Veranstaltet wird das Meeting von der eGenix.com GmbH, Langenfeld, in Zusammenarbeit mit Clark Consulting & Research, Düsseldorf: * http://www.egenix.com/ * http://www.clark-consulting.eu/ Mit freundlichen Grüßen, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Sep 16 2015) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ 2015-09-14: Released mxODBC Plone/Zope DA 2.2.3 http://egenix.com/go84 2015-09-18: PyCon UK 2015 ... 2 days to go 2015-09-26: Python Meeting Duesseldorf Sprint 2015 10 days to go eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Wed, Sep 16, 2015 at 6:24 PM, Ben Finney wrote: > Chris Angelico writes: > >> On Wed, Sep 16, 2015 at 6:14 PM, Gregory Ewing >> wrote: >> > This suggests an alternative model for Python computation. All data >> > is represented by cats. A variable is a box containing a cat. >> > Assignment replaces one cat with an entangled copy of another cat, >> > so that mutating either one affects the other. >> >> Quantum computing is the way of the future! > > Tachyon computing is the way of the future *and* the past. What do we want? Guido's time machine!! When do we want it? Before feature freeze... unless we get an exemption... actually, yaknow, it doesn't much matter. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: From logging to files to a better solution: syslog, Sentry, Logstash, ....
Am Mittwoch, 16. September 2015 07:58:11 UTC+2 schrieb dieter:
> Thomas Güttler writes:
> > Am Freitag, 11. September 2015 11:03:52 UTC+2 schrieb jmp:
> > ...
> >> Something like (python 2.7)
> >>
> >> import logging
> >>
> >> logCfg = {
> >> 'remote':(
> >> logging.StreamHandler(),
> >> logging.Formatter('Remote - %(levelname)s - %(message)s'),
> >> logging.INFO,
> >> ),
> >> 'vpn':(
> >> logging.StreamHandler(),
> >> logging.Formatter('VPN - %(levelname)s - %(message)s'),
> >> logging.ERROR,
> >> ),
> >> }
> >
> >
> > Yes, I could do it this way.
> >
> > But somehow I am not happy with this solution.
> >
> > I think the filtering should be outside of python.
>
> Do you think, it will be easier there?
>
> You could also use the "syslog" handler and use "syslog"
> configuration features to separate the various message levels.
> >From my point of view, this will not be easier - but outside of Python :-)
>
> And you can develop your own Python logging handler delegating logging to
> your favorite external logging subsystem and then configure that.
> Likely the hardest approach...
Yes, this is a python list. I like python programming.
But I don't want to solve everything with one tool.
I wanted to know how python folks handle their logs.
I think filtering mails should be done outside the python interpreter.
Strange that no one seems to use one of the mentioned tools for log handling.
Regards,
Thomas
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
Op 16-09-15 om 03:13 schreef Steven D'Aprano: > On Mon, 14 Sep 2015 06:30 pm, Antoon Pardon wrote: > >> Op 12-09-15 om 05:48 schreef Steven D'Aprano: >>> I believe I already acknowledged that assignment-as-expression was fine >>> if it avoided the = versus == error, from the perspective of avoiding >>> errors. But from the perspective of a clean and logical programming >>> model, perhaps not so much. Assignment is imperative, not functional, and >>> requiring it to return a result is somewhat unclean. >> I thought practicallity beats purity? AFAICS python doesn't use such a >> clean and logical programming model and it isn't given much critique over >> it. So I don't think it is fair to critique assignment as an expression >> because of this aspect. > Python is a remarkably clean and consistent language. Which is beside the point. Python may generally be a remarkable clean and consistent language, we were not discussing the language in general but a specific aspect. Arguing against C because it doesn't makes a clear seperation between questions and actions (because the assignment is an expression) while python doesn't either (but in other places) strikes me as disingineous. >> But we are not talking about all commands, we are just talking about >> assignments. Sure an assignment has a side effect. But so has ls.pop(). So >> something having a side-effect and a value is not unheard of even within a >> python context. > Sure, I already said that some commands might return a value. > > But assignment? Assignment is a pure command. There's nothing to return. > Having `x = 23` return 23 is, well, weird. If we start from the premise > that a return result is generated from a *calculation* or a *query*, we > have to ask what is being calculated or asked? You are stating your opinion as fact. Suppose I write the following class class SetGet: def __init__(self, value): self.val = value def get(self): return self.val def set(self, value): self.val = value return value So now I can write the following index = SetGet(0) while index.set(index.get() + 1) < 10: do_what_ever So how would you answer your question as to what is calculated or asked in the while condition here? The answer would be similar if we had just allowed an assignment in the condition. > And one other reason why I dislike it: it makes for a verbose and messy > interactive experience. Take Ruby: We are not talking about likes and dislikes. This discussion started by you stating the the assignment as an expression in C was a design flaw in the language. I can understand people preferring the assignment not to be an operator. But when people start suggesting that assignment as an operator is some kind of design flaw, which they use to criticise a specific language, personal likes and dislikes are not important. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Reading in large logfiles, and processing lines in batches - maximising throughput?
I'm using Python to parse metrics out of logfiles.
The logfiles are fairly large (multiple GBs), so I'm keen to do this in a
reasonably performant way.
The metrics are being sent to a InfluxDB database - so it's better if I can
batch multiple metrics into a batch ,rather than sending them individually.
Currently, I'm using the grouper() recipe from the itertools documentation to
process multiples lines in "chunks" - I then send the collected points to the
database:
def grouper(iterable, n, fillvalue=None):
"Collect data into fixed-length chunks or blocks"
# grouper('ABCDEFG', 3, 'x') --> ABC DEF Gxx
args = [iter(iterable)] * n
return zip_longest(fillvalue=fillvalue, *args)
with open(args.input_file, 'r') as f:
line_counter = 0
for chunk in grouper(f, args.batch_size):
json_points = []
for line in chunk:
line_counter +=1
# Do some processing
json_points.append(some_metrics)
if json_points:
write_points(logger, client, json_points, line_counter)
However, not every line will produce metrics - so I'm batching on the number of
input lines, rather than on the items I send to the database.
My question is, would it make sense to simply have a json_points list that
accumulated metrics, check the size each iteration and then send them off when
it reaches a certain size. Eg.:
BATCH_SIZE = 1000
with open(args.input_file, 'r') as f:
json_points = []
for line_number, line in enumerate(f):
# Do some processing
json_points.append(some_metrics)
if len(json_points) >= BATCH_SIZE:
write_points(logger, client, json_points, line_counter)
json_points = []
Also, I originally used grouper because I thought it better to process lines in
batches, rather than individually. However, is there actually any throughput
advantage from doing it this way in Python? Or is there a better way of getting
better throughput?
We can assume for now that the CPU load of the processing is fairly light
(mainly string splitting, and date parsing).
--
https://mail.python.org/mailman/listinfo/python-list
python how to load multiple C libraries
hi: I encountered a problem. I use ctypes load multiple C libraries, but the libraries have dependence each other.So, how can i load these libraries. For example, I have two libraries:A、B, but A depends on B, B depends on A. So how do I load them? Is there anybody know how to do it? -- https://mail.python.org/mailman/listinfo/python-list
Re: Reading in large logfiles, and processing lines in batches - maximising throughput?
On Wed, Sep 16, 2015 at 7:27 PM, Victor Hooi wrote: > Also, I originally used grouper because I thought it better to process lines > in batches, rather than individually. However, is there actually any > throughput advantage from doing it this way in Python? Or is there a better > way of getting better throughput? > I very much doubt it'll improve throughput; what you're doing there is reading individual lines, then batching them up into blocks of 1000, and then stepping through the batches. In terms of disk read performance, you're already covered, because the file object should be buffered; if you're not doing much actual work in Python, that's probably where your bottleneck is. But keep in mind the basic rules of performance optimization: 1) Don't. 2) For experts only: Don't yet. 3) Measure first. If you remember only the first rule, you're going to be correct most of the time. Write your code to be idiomatic and clean, and *don't worry* about performance. The second rule comes into play once you have a fully working program, and you find that it's running too slowly. (For example, you run "cat filename >/dev/null" and it takes half a second, but you run your program on the same input file and it takes half a day.) Okay, so you know your program needs some work. But which parts of it are actually taking the time? If you just stare at your code and make a guess, *you will be wrong*. So you follow the third rule: Add a boatload of timing marks to the code. They'll slow it down, of course, but you'll usually find that large slabs of the code are so fast you can't even measure the time they're taking, so there's no point optimizing them in any way. Only once you've proven (a) that your program is "too slow" (for some measure of "slow"), and (b) that it's _this part_ that's taking the bulk of the time, *then* you can start improving performance. So get rid of the grouper; it's violating all three rules. Give the program a try without it, and see if you actually have a problem at all. Maybe you don't! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python how to load multiple C libraries
On Wed, Sep 16, 2015 at 7:35 PM, [email protected] wrote: > I encountered a problem. I use ctypes load multiple C libraries, but the > libraries have dependence each other.So, how can i load these libraries. For > example, I have two libraries:A、B, but A depends on B, B depends on A. So > how do I load them? Is there anybody know how to do it? How are the libraries built? A circular dependency is always a problem. How would a C program handle this? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python how to load multiple C libraries
hi: Most current compilers and linkers will search all object files, regard-less of order, but since not all compilers do this it is best to follow the convention of ordering object files from left to right . Python do that. So, is there anybody know how to solve the follow problem? On 09/16/2015 05:41 PM, Chris Angelico wrote: On Wed, Sep 16, 2015 at 7:35 PM, [email protected] wrote: I encountered a problem. I use ctypes load multiple C libraries, but the libraries have dependence each other.So, how can i load these libraries. For example, I have two libraries:A、B, but A depends on B, B depends on A. So how do I load them? Is there anybody know how to do it? How are the libraries built? A circular dependency is always a problem. How would a C program handle this? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
True == 1 weirdness
I am maintaining some old code where the programmer used 1 for True because
booleans hadn't been added to Python yet. I'm getting some weird behaviour, so
I created some simple tests to illustrate my issue.
>>> 1 in {1:1}#test1
True
>>> 1 in {1:1} == 1 #test2
False
>>> (1 in {1:1}) == 1 #test3
True
>>> 1 in ({1:1} == 1) #test4
Traceback (most recent call last):
File "", line 1, in
TypeError: argument of type 'bool' is not iterable
>>>
You can see that in the first test we get True as expected. The second test
yield False, because True does not equal 1, apparently. Fair enough. But then
the third test yields True. Weird. Okay, so maybe it was evaluating the right
side first? So I put the parens over to the right and it fails, so that wasn't
it. So why do the second and third test differ?
--
https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
Blake T. Garretson writes:
> I am maintaining some old code where the programmer used 1 for True
> because booleans hadn't been added to Python yet. I'm getting some
> weird behaviour, so I created some simple tests to illustrate my
> issue.
>
> >>> 1 in {1:1}#test1
> True
> >>> 1 in {1:1} == 1 #test2
> False
> >>> (1 in {1:1}) == 1 #test3
> True
> >>> 1 in ({1:1} == 1) #test4
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: argument of type 'bool' is not iterable
> >>>
Ouch. I love chained comparisons more than most people, but this took a
while to decipher. I blame you! Your parentheses mis-primed me for the
wrong reading :) But now I expect to see a long thread about whether
chained comparisons are a natural thing to have in the language.
The second test, test2, is interpreted (almost) as
(1 in {1:1}) and ({1:1} == 1)
which is obviously False.
--
https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Wed, Sep 16, 2015 at 10:53 PM, Jussi Piitulainen
wrote:
> Ouch. I love chained comparisons more than most people, but this took a
> while to decipher. I blame you! Your parentheses mis-primed me for the
> wrong reading :) But now I expect to see a long thread about whether
> chained comparisons are a natural thing to have in the language.
>
> The second test, test2, is interpreted (almost) as
>
> (1 in {1:1}) and ({1:1} == 1)
>
> which is obviously False.
My view is that they should remain in the language, but that
dissimilar comparisons should raise linter warnings. I can't imagine a
sane reason for chaining 'in' and equality like that (since the RHS of
'in' will be a container, and if you're testing the whole container
for equality, you probably don't care about one member in it), but for
language consistency, it's good to support it.
Chained comparisons of the same type are a great feature:
if 1 < x < 4:
And "same type" doesn't just mean the exact same operator:
if 1 < x <= 4:
It's only when you mix them up in bizarre ways that it's getting a bit weird.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 09/16/2015 02:16 PM, Blake T. Garretson wrote:
1 in {1:1} == 1 #test2
The second test yield False, because True does not equal 1, apparently. Fair
enough.
No, it yields False because {1:1} == 1 is false. Test 2 looks actually like
(1 in {1:1}) and ({1:1} == 1).
Which in your example does not make any sense but think of this one:
x = 5
3 < x < 10
JM
--
https://mail.python.org/mailman/listinfo/python-list
Re: python how to load multiple C libraries
In a message of Wed, 16 Sep 2015 17:35:18 +0800, "[email protected]" write s: >hi: >I encountered a problem. I use ctypes load multiple C libraries, but >the libraries have dependence each other.So, how can i load these >libraries. For example, I have two libraries:A、B, but A depends on B, B >depends on A. So how do I load them? Is there anybody know how to do it? I don't know how to do this with ctypes (which doesn't mean it cannot be done, just that I haven't ever wanted to do this). What happens if you make a small file that loads both separately and loads that one first? It may be that you can get what you want with by loading the first lib RTLD_LAZY instead of RTLD_NOW. see: http://stackoverflow.com/questions/22591472/dyanamic-library-linking-by-rtld-lazy see: this very old thread, maybe CTypes knows about it now. http://osdir.com/ml/python.ctypes/2006-10/msg00029.html But I have never tried. These days I used cffi instead of ctypes. If you use cffi https://pypi.python.org/pypi/cffi there should not be any problem if you use ffi.set_source(), only once, but mentioning both libs in the libraries=[...] argument. Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Wednesday, September 16, 2015 at 8:54:07 AM UTC-4, Jussi Piitulainen wrote:
> The second test, test2, is interpreted (almost) as
>
> (1 in {1:1}) and ({1:1} == 1)
>
> which is obviously False.
Ah, that makes sense. It didn't occur to me that Python would interpret it
that way, and I've been using Python daily for 15 years. I try to avoid
ambiguous chained comparisons, and I use parenthesis even when I don't need
them for clarity. Thanks!
--
https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Wednesday, September 16, 2015 at 9:08:54 AM UTC-4, jmp wrote: > x = 5 > 3 < x < 10 That's a great example. I use this case all the time and didn't think to apply the same principal to the in/== case. I assumed that "in" was evaluated first, and then the == comparison was made. Thanks! -- https://mail.python.org/mailman/listinfo/python-list
datetime.datetime.today()
This surprised me today: >>> import datetime >>> datetime.datetime.today(), datetime.datetime.now() (datetime.datetime(2015, 9, 16, 8, 44, 7, 723560), datetime.datetime(2015, 9, 16, 8, 44, 7, 723577)) I naively expected today() to always return a datetime.date object. Oh well, bug in my code has been squashed. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: datetime.datetime.today()
> This surprised me today: > > >>> import datetime > >>> datetime.datetime.today(), datetime.datetime.now() > (datetime.datetime(2015, 9, 16, 8, 44, 7, 723560), datetime.datetime(2015, > 9, 16, 8, 44, 7, 723577)) > > I naively expected today() to always return a datetime.date object. Oh > well, bug in my code has been squashed. > Just in the case you didn't figure it out: >>> datetime.datetime.today() datetime.datetime(2015, 9, 16, 14, 50, 47, 700828) >>> datetime.date.today() datetime.date(2015, 9, 16) You were accessing the today method of the datetime property which inevitably returns a datetime object. Getting today from the date object will return an actual date. Now and today are very, very, similar - but now may be more accurate and gives flexibility with timezones as per https://docs.python.org/3/library/datetime.html#datetime.datetime.now - Nick -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Wed, Sep 16, 2015, at 09:05, Chris Angelico wrote: > My view is that they should remain in the language, but that > dissimilar comparisons should raise linter warnings. I can't imagine a > sane reason for chaining 'in' and equality like that (since the RHS of > 'in' will be a container, and if you're testing the whole container > for equality, you probably don't care about one member in it), but for > language consistency, it's good to support it. > > Chained comparisons of the same type are a great feature: Do chained "in" comparisons ever really make sense, even when they're all the same type? I mean, I suppose 1 in (1, 2) in ((1, 2), (3, 4)) is technically true, but how useful is it really? -- https://mail.python.org/mailman/listinfo/python-list
Re: datetime.datetime.today()
On Wed, Sep 16, 2015 at 8:55 AM, Nick Sarbicki wrote: > Just in the case you didn't figure it out: > > >>> datetime.datetime.today() > datetime.datetime(2015, 9, 16, 14, 50, 47, 700828) > >>> datetime.date.today() > datetime.date(2015, 9, 16) > Yeah, I was aware of that. That is partly why I thought datetime.datetime.today() would return a date object. In English, "today" and "now" mean different things, so it makes some sense that they would behave differently as methods of datetime objects. Thx, S -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Thu, Sep 17, 2015 at 12:03 AM, Random832 wrote: > On Wed, Sep 16, 2015, at 09:05, Chris Angelico wrote: >> My view is that they should remain in the language, but that >> dissimilar comparisons should raise linter warnings. I can't imagine a >> sane reason for chaining 'in' and equality like that (since the RHS of >> 'in' will be a container, and if you're testing the whole container >> for equality, you probably don't care about one member in it), but for >> language consistency, it's good to support it. >> >> Chained comparisons of the same type are a great feature: > > Do chained "in" comparisons ever really make sense, even when they're > all the same type? > > I mean, I suppose 1 in (1, 2) in ((1, 2), (3, 4)) is technically true, > but how useful is it really? Quite probably never. But are there _any_ comparison operators which are unchainable? If not, there's no reason to disallow 'in'; this is the distinction between language-level features and usage recommendations. All comparisons can be chained, and the semantics of (X op1 Y op2 Z) will always be ((X op1 Y) and (Y op2 Z)) but with Y evaluated only once. That definition is fairly simple, and even though it's a little wordy, it makes perfect sense; and the rule "all comparisons" is way WAY simpler than "this specific set of chainable operators", even if the only ones you'd ever actually want to chain are the classic numeric operators (==, !=, <, >, <=, >=). According to the operator precedence table [1], all comparison operators stand together, and dividing that would mean making a once-for-everyone decision about which are plausibly chainable. Remember, the language rules can't know what kinds of objects we're working with; I can write a __contains__ method that does whatever I want, but I can't decide whether or not 'x in y in z' is evaluated as 'x in y and y in z', or '(x in y) in z', or 'x in (y in z)', no matter what the types of x, y, and z. Far as I can see, the only operator that you might want to disallow chaining on is 'in' (and its mate 'not in', of course). It isn't common, but "x is y is z is None" is a perfectly reasonable way to ascertain whether or not they're all None, just as "x = y = z = None" is a perfectly reasonable way to set them all to None; the arguments as to whether it should be "the wordy operators don't chain" or "everything except 'in' chains" would be interminable. Much simpler to stick with "all operators chain", which (conveniently) is status quo. :) ChrisA [1] https://docs.python.org/3/reference/expressions.html#operator-precedence -- https://mail.python.org/mailman/listinfo/python-list
Re: [Tutor] Is context manager the answer to synchronous function calls?
On Wed, Sep 16, 2015 at 7:54 AM, Mark Lawrence wrote: > > Assuming your (Alan's) guess is correct, and I certainly agree it's > plausible, I suspect this might be better asked on the main Python mailing > list, I don't see this as tutor material. > > Sorry first time posting to tutor / general list. Usually on TIP list. As per Mark's recommendation, now posting to [email protected]. On Wed, Sep 16, 2015 at 6:56 AM, Alan Gauld wrote: > > You don't actually specify but I'm guessing VM > means Virtual Machine? Is it a specific type > of VM? eg VMWare/VirtualBox or somesuch, or is > it more of a sandbox environment like virtualenv? > That might help us understand the restrictions better. In my case my underlying functions will use boto (Amazon Web Service's Python SDK) but I thought to abstract the details away from posting because as you know I want to simply return an object. But yes, boto will simply return the call with a response object. For example, to create an RDS database, the call is returned and I will to query for the status of the database before I can perform further actions to the instance such as changing password (which is covered in the modify_vm function call). But creating VM such as EC2 has an equal synchronous nature. I would be tempted to use an asynchronous approach with a > when_ready() function that takes my function as an input > parameter. You could then run the when_ready in a thread > or, I suspect, utilize the asyncio or asyncore modules, > although I haven't tried using them for this kind of > thing myself. > The bottom line is you need to wait for the status to > change. How you do that wait is up to you but you can > make it more readable for the user. The easier it is for > the user the harder it will be for you. > > Sounds like to make it readable and user friendly, also to have separation of concern, I almost am locked into implementing in OOP style. Imperative seems to be okay but lack the "shininess." Thank you. John -- https://mail.python.org/mailman/listinfo/python-list
RE: True == 1 weirdness
In terms of operator precedence, is "==" evaluated before "in"? *-*-*- PRESBYTERIAN_HEALTHCARE_SERVICES_DISCLAIMER -*-*-* This message originates from Presbyterian Healthcare Services or one of its affiliated organizations. It contains information, which may be confidential or privileged, and is intended only for the individual or entity named above. It is prohibited for anyone else to disclose, copy, distribute or use the contents of this message. All personal messages express views solely of the sender, which are not to be attributed to Presbyterian Healthcare Services or any of its affiliated organizations, and may not be distributed without this disclaimer. If you received this message in error, please notify us immediately at [email protected]. If you would like more information about Presbyterian Healthcare Services please visit our web site http://www.phs.org -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 2015-09-16 10:03, Random832 wrote: > Do chained "in" comparisons ever really make sense, even when > they're all the same type? > > I mean, I suppose 1 in (1, 2) in ((1, 2), (3, 4)) is technically > true, but how useful is it really? I could concoct a "useful" example where "in" is involved in a chain, something like set_of_valid_ids = generate_valid_ids_maybe_negative() if 0 < i in set_of_valid_ids: do_something(i) This would unpack as "if 0 > i and i in set_of_valid_ids". However the "useful"ness of it doesn't outweigh the horrible readability IMHO. So I'd never actually *use* this, even if it might be "useful". -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: [Tutor] Is context manager the answer to synchronous function calls?
On Thu, Sep 17, 2015 at 12:34 AM, John Wong wrote: > Sorry first time posting to tutor / general list. Usually on TIP list. As > per Mark's recommendation, now posting to [email protected]. But, sadly, without a lot of context. When you change lists, it's helpful to include a lot of extra verbiage so folks who don't follow the other list can pick up where you were. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Wed, Sep 16, 2015 at 11:45 PM, Watson, Paul wrote: > In terms of operator precedence, is "==" evaluated before "in"? No, they're at the same precedence level. Within that, all comparison operators are evaluated left-to-right, with the chaining that was described earlier. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: datetime.datetime.today()
This bit me once. I was comparing a date to a datetime, both representing the same day, so I expected them to be the same, but I was wrong. What I should have done was extracting the date of the datetime with the .date() function, and only then compare it to the other date: >>> import datetime >>> a = datetime.datetime.today() >>> a datetime.datetime(2015, 9, 16, 16, 57, 45, 150069) >>> b = datetime.date.today() >>> a == b False >>> a.date() datetime.date(2015, 9, 16) >>> a.date() == b True Greetings, -- https://mail.python.org/mailman/listinfo/python-list
Re: broken install?
The installer should detect that it is being run on an unsupported system and do something helpful. -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Wed, Sep 16, 2015, at 10:26, Chris Angelico wrote: > Quite probably never. But are there _any_ comparison operators which > are unchainable? If not, there's no reason to disallow 'in' "in" suggests a relationship between objects of different types (X and "something that can contain X") - all the other comparison operators are meant to work on objects of the same or similar types. Why not make isinstance a comparison operator and have "1 instanceof int instanceof type"? Having chaining apply to things that are not *semantically* comparisons is just baffling. >; this is > the distinction between language-level features and usage > recommendations. All comparisons can be chained, and the semantics of > (X op1 Y op2 Z) will always be ((X op1 Y) and (Y op2 Z)) but with Y > evaluated only once. That definition is fairly simple, and even though > it's a little wordy, it makes perfect sense; and the rule "all > comparisons" is way WAY simpler than "this specific set of chainable > operators", It's the same thing - you've just named that set "comparisons". I don't think "in" is semantically a comparison at all. -- https://mail.python.org/mailman/listinfo/python-list
Re: broken install?
On Thu, Sep 17, 2015 at 1:26 AM, wrote: > The installer should detect that it is being run on an unsupported system > and do something helpful. Fair point. Want to raise a tracker issue on bugs.python.org about it? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
Chris Angelico : > Far as I can see, the only operator that you might want to disallow > chaining on is 'in' (and its mate 'not in', of course). It isn't > common, but "x is y is z is None" is a perfectly reasonable way to > ascertain whether or not they're all None, just as "x = y = z = None" > is a perfectly reasonable way to set them all to None; Then you can have: first_node is not node is not last_node No, seriously, that's not reasonable. Frankly, I don't think chaining was all that great of an idea. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 16.09.2015 18:16, Marko Rauhamaa wrote: Chris Angelico : Far as I can see, the only operator that you might want to disallow chaining on is 'in' (and its mate 'not in', of course). It isn't common, but "x is y is z is None" is a perfectly reasonable way to ascertain whether or not they're all None, just as "x = y = z = None" is a perfectly reasonable way to set them all to None; Then you can have: first_node is not node is not last_node No, seriously, that's not reasonable. Frankly, I don't think chaining was all that great of an idea. I like it for x < y < z. But I agree more than this often helps confusion more than it helps clarity. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
"Sven R. Kunze" : > On 16.09.2015 18:16, Marko Rauhamaa wrote: >> Frankly, I don't think chaining was all that great of an idea. > > I like it for x < y < z. > > But I agree more than this often helps confusion more than it helps > clarity. I see what you did there. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Wed, Sep 16, 2015, at 12:37, Sven R. Kunze wrote: > I like it for x < y < z. > > But I agree more than this often helps confusion more than it helps > clarity. I think that chaining should be limited to: A) all operators are "=" B) all operators are "is" C) all operators are either >= or > D) all operators are either <= or < There's no other scenario, if the operators have natural meanings, that it would actually be natural to write it that way. (Actually, I'm not entirely convinced any harm would be done by allowing you to put "is"/= anywhere, but there certainly shouldn't be opposite direction comparisons, "is not", !=, or "in".) Certainly I think this should be enforced by any sort of lint tool, even if the other uses are not actually removed from the language. I also think it should be part of PEP 8. -- https://mail.python.org/mailman/listinfo/python-list
Python 3 unbuffered IO
What is the best way to determine if a file object is unbuffered?
In Python 3.4, if I open the file with buffering=0, I get a FileIO object.
>>> fh = open("tmp", "rb+", buffering=0)
>>> fh
<_io.FileIO name='tmp' mode='rb+'>
Is the FileIO object always unbuffered?
If I open it without buffering=0, I get a BufferedRandom.
>>> fh = open("tmp", "rb+")
>>> fh
<_io.BufferedRandom name='tmp'>
Should I just compare the file object class to determine buffering?
Ultimately, I'd like to determine when a file object is unbuffered to fix an
issue in a CPython section of numpy.
Thanks for your help!
--
https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 16.09.2015 18:57, Random832 wrote: I think that chaining should be limited to: A) all operators are "=" B) all operators are "is" C) all operators are either >= or > D) all operators are either <= or < That certainly would be a fine guideline. Only use it with all operators the same. Everything else might cause headaches. Restricting it language-wise? I don't know. I have to admit I've never seen this in production anyway. Most languages I see people working with don't have this feature at all. So, they don't know it exists in Python. Best, Sven -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Thu, 17 Sep 2015 12:03 am, Random832 wrote:
> Do chained "in" comparisons ever really make sense, even when they're
> all the same type?
>
> I mean, I suppose 1 in (1, 2) in ((1, 2), (3, 4)) is technically true,
> but how useful is it really?
if fly in spider in rat in cat in dog in old_woman:
print("I don't know why she swallowed the fly")
For a less whimsical example:
if word in line in text:
print("word in line and line in text")
But I agree with Tim Chase: I wouldn't use it, even though it's legal.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 2015-09-16, Sven R. Kunze wrote: > On 16.09.2015 18:57, Random832 wrote: >> I think that chaining should be limited to: >> >> A) all operators are "=" >> B) all operators are "is" >> C) all operators are either >= or > >> D) all operators are either <= or < > > That certainly would be a fine guideline. Only use it with all operators > the same. I find that the only times I use chaining (intentionally), are in cases C and D. All other instances of chaining in my code are invariably typos/bugs. > Everything else might cause headaches. I'm not all that sure A and B should be allowed. > Restricting it language-wise? I don't know. I have to admit I've never > seen this in production anyway. Most languages I see people working with > don't have this feature at all. So, they don't know it exists in Python. I use C and D intentionally, and have tripped accidentally over other cases. -- Grant Edwards grant.b.edwardsYow! Hey, waiter! I want at a NEW SHIRT and a PONY TAIL gmail.comwith lemon sauce! -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Thu, 17 Sep 2015 01:40 am, Random832 wrote: > "in" suggests a relationship between objects of different types (X and > "something that can contain X") - all the other comparison operators are > meant to work on objects of the same or similar types. `is` and the equality operators are intended to work on arbitrary objects, as are their inverses `is not` and inequality. And with operator overloading, < <= > and => could have any meaning you like: graph = a => b => c <= d <= e > Why not make isinstance a comparison operator and have "1 instanceof int > instanceof type"? Having chaining apply to things that are not > semantically comparisons is just baffling. Somewhat ugly, I grant you, but if baffling? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Wed, Sep 16, 2015, at 13:24, Steven D'Aprano wrote:
> On Thu, 17 Sep 2015 12:03 am, Random832 wrote:
>
> if word in line in text:
> print("word in line and line in text")
>
> But I agree with Tim Chase: I wouldn't use it, even though it's legal.
I just had another thought on *why* the other cases make me so uneasy.
The reason this is reasonable for simple cases like a > b > c or a < b
<= c is that, in their normal meanings, these operations are transitive.
a > b and b > c implies a > c. a < b and b <= c implies a < c. This is
also a good reason for allowing "==" or "is" anywhere - because it's a
natural way to write a graph including an equivalence class: a < b == c
< d implies b < d, a < c, and a < d. So it's a natural way of writing
it. On the other hand, a in b in c doesn't imply a in c for several
common cases, and a > b < c doesn't imply anything about the
relationship between a and c, so it really shouldn't be a single
expression.
A chained comparison doesn't *actually* compare non-adjacent elements,
but with well-defined transitive relationships (or... semi-transitive?
is there a word for this? My point being that when you include some ==
or mix <= and < together, it still allows you to make some statements
about their relationships), you are essentially saying "a, b, c are
ordered". The generalization to mixing arbitrary operators loses this
aspect.
--
https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 9/16/2015 10:27 AM, Grant Edwards wrote: On 2015-09-16, Sven R. Kunze wrote: On 16.09.2015 18:57, Random832 wrote: I think that chaining should be limited to: A) all operators are "=" B) all operators are "is" C) all operators are either >= or > D) all operators are either <= or < I'm not all that sure A and B should be allowed. I find A convenient for initializing: aname = bname = cname = None Nut I don't recall ever having used is this way. Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Thu, 17 Sep 2015 02:57 am, Random832 wrote: > I think that chaining should be limited to: > > A) all operators are "=" > B) all operators are "is" > C) all operators are either >= or > > D) all operators are either <= or < > > There's no other scenario, if the operators have natural meanings, that > it would actually be natural to write it that way. 0 <= x < y == z The main reason for supporting arbitrary chained operators is that they could be overloaded and have some meaning that makes sense: node = left <= ptr => right -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 16.09.2015 19:33, Steven D'Aprano wrote: On Thu, 17 Sep 2015 01:40 am, Random832 wrote: "in" suggests a relationship between objects of different types (X and "something that can contain X") - all the other comparison operators are meant to work on objects of the same or similar types. `is` and the equality operators are intended to work on arbitrary objects, as are their inverses `is not` and inequality. And with operator overloading, < <= > and => could have any meaning you like: graph = a => b => c <= d <= e Sorry? What are you trying to do here? Why not make isinstance a comparison operator and have "1 instanceof int instanceof type"? Having chaining apply to things that are not semantically comparisons is just baffling. Somewhat ugly, I grant you, but if baffling? -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Wed, Sep 16, 2015, at 13:33, Steven D'Aprano wrote: > On Thu, 17 Sep 2015 01:40 am, Random832 wrote: > > > "in" suggests a relationship between objects of different types (X and > > "something that can contain X") - all the other comparison operators are > > meant to work on objects of the same or similar types. > > `is` and the equality operators are intended to work on arbitrary > objects, > as are their inverses `is not` and inequality. But they won't return *true* unless they're the same or similar types. > And with operator overloading, < <= > and => could have any meaning you > like: > > graph = a => b => c <= d <= e Are you suggesting that all objects concerned are a magical "graph node object", the <= and [sic] => operators of which return "edge objects", the and operator of which constructs a graph object containing all such edges? That's *horrifying*. And won't actually work. We haven't actually got an => operator, thankfully, and you can't overload 'and'. I bet you could do it in C++ though. -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Thu, 17 Sep 2015 03:27 am, Grant Edwards wrote: > On 2015-09-16, Sven R. Kunze wrote: >> On 16.09.2015 18:57, Random832 wrote: >>> I think that chaining should be limited to: >>> >>> A) all operators are "=" >>> B) all operators are "is" [...] > I'm not all that sure A and B should be allowed. You can take `x == y == z` off me when you pry it from my cold, dead hands. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
Steven D'Aprano : > The main reason for supporting arbitrary chained operators is that > they could be overloaded and have some meaning that makes sense: Operator overloading is yet another unfortunate language feature. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 2015-09-16, Steven D'Aprano wrote: > On Thu, 17 Sep 2015 03:27 am, Grant Edwards wrote: > >> On 2015-09-16, Sven R. Kunze wrote: >>> On 16.09.2015 18:57, Random832 wrote: I think that chaining should be limited to: A) all operators are "=" B) all operators are "is" > > [...] >> I'm not all that sure A and B should be allowed. > > You can take `x == y == z` off me when you pry it from my cold, dead hands. Well, that case hadn't been mentioned yet. But, I agree that should be added as case E and be allowed. -- Grant Edwards grant.b.edwardsYow! ... or were you at driving the PONTIAC that gmail.comHONKED at me in MIAMI last Tuesday? -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 2015-09-16, Random832 wrote: > On Wed, Sep 16, 2015, at 13:33, Steven D'Aprano wrote: [...] >> graph = a => b => c <= d <= e > > Are you suggesting that all objects concerned are a magical "graph node > object", the <= and [sic] => operators of which return "edge objects", > the and operator of which constructs a graph object containing all such > edges? That's *horrifying*. And won't actually work. We haven't actually > got an => operator, thankfully, and you can't overload 'and'. > > I bet you could do it in C++ though. If that isn't a damning indictment, I don't know what is. :) -- Grant Edwards grant.b.edwardsYow! I wish I was a at sex-starved manicurist gmail.comfound dead in the Bronx!! -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Wed, Sep 16, 2015, at 13:44, Grant Edwards wrote: > Well, that case hadn't been mentioned yet. But, I agree that should be > added as case E and be allowed. That's actually what I meant by A, I just spelled it wrong. Multiple assignment isn't really the same construct as chained comparisons, I didn't consider it in scope for this discussion. -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Wed, Sep 16, 2015 at 11:44 AM, Grant Edwards wrote: > On 2015-09-16, Steven D'Aprano wrote: >> On Thu, 17 Sep 2015 03:27 am, Grant Edwards wrote: >> >>> On 2015-09-16, Sven R. Kunze wrote: On 16.09.2015 18:57, Random832 wrote: > I think that chaining should be limited to: > > A) all operators are "=" > B) all operators are "is" >> >> [...] >>> I'm not all that sure A and B should be allowed. >> >> You can take `x == y == z` off me when you pry it from my cold, dead hands. > > Well, that case hadn't been mentioned yet. But, I agree that should be > added as case E and be allowed. It was mentioned as case A, albeit mistakenly using "=" (which isn't even a comparison operator) instead of "==". -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 16.09.2015 19:36, Random832 wrote: I just had another thought on *why* the other cases make me so uneasy. The reason this is reasonable for simple cases like a > b > c or a < b <= c is that, in their normal meanings, these operations are transitive. a > b and b > c implies a > c. a < b and b <= c implies a < c. This is also a good reason for allowing "==" or "is" anywhere - because it's a natural way to write a graph including an equivalence class: a < b == c < d implies b < d, a < c, and a < d. So it's a natural way of writing it. On the other hand, a in b in c doesn't imply a in c for several common cases, and a > b < c doesn't imply anything about the relationship between a and c, so it really shouldn't be a single expression. A chained comparison doesn't *actually* compare non-adjacent elements, but with well-defined transitive relationships (or... semi-transitive? is there a word for this? My point being that when you include some == or mix <= and < together, it still allows you to make some statements about their relationships), you are essentially saying "a, b, c are ordered". The generalization to mixing arbitrary operators loses this aspect. Well said! -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 2015-09-16, Steven D'Aprano wrote: > On Thu, 17 Sep 2015 02:57 am, Random832 wrote: > > >> I think that chaining should be limited to: >> >> A) all operators are "=" >> B) all operators are "is" >> C) all operators are either >= or > >> D) all operators are either <= or < >> >> There's no other scenario, if the operators have natural meanings, that >> it would actually be natural to write it that way. > > > 0 <= x < y == z > > The main reason for supporting arbitrary chained operators is that they > could be overloaded and have some meaning that makes sense: In my experience, that just doesn't happen. Yes, they can be overloaded, but doing that and then chaining them isn't going to make sense to anybody but the author (and temporarily even then). > node = left <= ptr => right Exactly. I've no clue what that means. ;) -- Grant Edwards grant.b.edwardsYow! Zippy's brain cells at are straining to bridge gmail.comsynapses ... -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Wed, Sep 16, 2015 at 11:24 AM, Steven D'Aprano wrote:
>
> if word in line in text:
> print("word in line and line in text")
It find it hard to imagine how one would arrive at the situation of
needing to check this.
--
https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 9/16/2015 10:42 AM, Marko Rauhamaa wrote: Steven D'Aprano : The main reason for supporting arbitrary chained operators is that they could be overloaded and have some meaning that makes sense: Operator overloading is yet another unfortunate language feature. dunder methods are there for consenting adults -- I don't consider it a wart. Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging and deployment of standalone Python applications?
Am 15.09.2015 um 08:59 schrieb [email protected]: https://docs.python.org/3/library/venv.html?highlight=venv#module-venv Thanks, this already is pretty close to what I need. Playing with this and virtualenv, I figured out that this way it's pretty easily possible to have isolated Python environments _locally_. However I failed to package one of these environments and move it to, say, from my Ubuntu development host to a remote Debian server, I end up with errors like these while trying to run the Python off the environment on that host: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found I bundled all the stuff in the virtualenv and also made sure to dereference the symlinks in there. Are Python binaries so closely tied to a particular Linux environment / distribution that what I am about to do is impossible? Is there a "generic" Python for Linux binary that works on all distributions, as things are for Java? TIA and all the best, Kristian -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 16.09.2015 19:39, Steven D'Aprano wrote: node = left <= ptr => right Wow. I have absolutely no idea what this is supposed to mean. Do you care to elaborate? Best, Sven -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 16.09.2015 19:46, Grant Edwards wrote: On 2015-09-16, Steven D'Aprano wrote: node = left <= ptr => right Exactly. I've no clue what that means. ;) Modern art. ;) Best, Sven -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 2015-09-16, Sven R. Kunze wrote: > On 16.09.2015 19:46, Grant Edwards wrote: >> On 2015-09-16, Steven D'Aprano wrote: >> >>> node = left <= ptr => right >> >> Exactly. I've no clue what that means. ;) > > Modern art. ;) Ah, well I know that _that_ means: "I think it exemplifies the angst and conflict inherent in modern society". You can say that while standing in front of any piece of modern art, and most everybody will just nod. Try it. -- Grant Edwards grant.b.edwardsYow! These PRESERVES should at be FORCE-FED to PENTAGON gmail.comOFFICIALS!! -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
"Sven R. Kunze" : > On 16.09.2015 19:39, Steven D'Aprano wrote: >> node = left <= ptr => right > > Wow. I have absolutely no idea what this is supposed to mean. Do you > care to elaborate? Python is an HC Language for HC Developers. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: [Tutor] Is context manager the answer to synchronous function calls?
Ah. Thanks.. I removed the previous code. Please excuse me. I will rewrite
the question so it is clear.
Here is my current solution in an imperative way. My application will work
with AWS boto library to create EC2 instances and RDS instances. Assuming
my API will simply send the request, and return if the request is accepted,
I need to lock until the instance is ready before I can start the next
operation.
def create_vm(.):
# returns vm object
def modify_vm(.):
return new vm object
def get_vm_status(.):
return status
# NOTE: This is obviously a simplified version, but pretty much half
of the code.
def lock_until_ready(conn, get_status_func, _id, max_wait=60):
wait_count = 1
status = get_status_func(conn, _id)
while status != 'available' and wait_count < max_wait:
print("Querying status (attempt {i}): {status}".format(
i=wait_count, status=status))
wait_count += 1
time.sleep(10)
status = get_status_func(conn, _id)
def clone(data_center, image_id, options):
conn = get_connection(data_center)
vm_id = create_vm(conn, image_id, )
lock_until_ready(conn, get_vm_status, vm_id, max_wait=30)
modify_vm(conn, options)
lock_until_ready(conn, get_vm_status, vm_id, max_wait=30)
I hope this doesn't come across as a code review. This works. I made my
lock function extensible and testable, but I feel like there should be a
better more user-friendly way, even in the imperative world in Python. I
thought of context manager because I can do some clean up on entry (verify
the db name has not been taken), and exit (if fail rollback). If you are
familiar with cloudformation, it almost seems like that's what I am doing.
I am writing this because I have custom needs that cloudformation can't do
elegantly without many hops. API is much more flexible for my current task,
FYI.
Any feedback is welcome. Thank you.
John
On Wed, Sep 16, 2015 at 10:53 AM, Chris Angelico wrote:
> On Thu, Sep 17, 2015 at 12:34 AM, John Wong wrote:
> > Sorry first time posting to tutor / general list. Usually on TIP list. As
> > per Mark's recommendation, now posting to [email protected].
>
> But, sadly, without a lot of context. When you change lists, it's
> helpful to include a lot of extra verbiage so folks who don't follow
> the other list can pick up where you were.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 16/09/2015 17:16, Marko Rauhamaa wrote: Chris Angelico : Far as I can see, the only operator that you might want to disallow chaining on is 'in' (and its mate 'not in', of course). It isn't common, but "x is y is z is None" is a perfectly reasonable way to ascertain whether or not they're all None, just as "x = y = z = None" is a perfectly reasonable way to set them all to None; Then you can have: first_node is not node is not last_node No, seriously, that's not reasonable. Frankly, I don't think chaining was all that great of an idea. Marko I disagree, perfectly logical where I sit. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 16/09/2015 18:41, Emile van Sebille wrote: On 9/16/2015 10:27 AM, Grant Edwards wrote: On 2015-09-16, Sven R. Kunze wrote: On 16.09.2015 18:57, Random832 wrote: I think that chaining should be limited to: A) all operators are "=" B) all operators are "is" C) all operators are either >= or > D) all operators are either <= or < I'm not all that sure A and B should be allowed. I find A convenient for initializing: aname = bname = cname = None Nut I don't recall ever having used is this way. Emile You're replying to a typo, it should have been "==" not "=". -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 16/09/2015 20:47, Grant Edwards wrote: On 2015-09-16, Sven R. Kunze wrote: On 16.09.2015 19:46, Grant Edwards wrote: On 2015-09-16, Steven D'Aprano wrote: node = left <= ptr => right Exactly. I've no clue what that means. ;) Modern art. ;) Ah, well I know that _that_ means: "I think it exemplifies the angst and conflict inherent in modern society". You can say that while standing in front of any piece of modern art, and most everybody will just nod. Try it. Is it:- modern art == crap or modern art = crap ? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 16/09/2015 18:53, Sven R. Kunze wrote: On 16.09.2015 19:39, Steven D'Aprano wrote: node = left <= ptr => right Wow. I have absolutely no idea what this is supposed to mean. Do you care to elaborate? Best, Sven Simple, straight forward easy to read bit of Python, where is the problem? node is bound to the boolean ptr is greater than or equal to left and right. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 09/16/2015 02:29 PM, Mark Lawrence wrote: > On 16/09/2015 18:53, Sven R. Kunze wrote: >> On 16.09.2015 19:39, Steven D'Aprano wrote: >>> node = left <= ptr => right >> >> Wow. I have absolutely no idea what this is supposed to mean. Do you >> care to elaborate? >> >> >> Best, >> Sven > > Simple, straight forward easy to read bit of Python, where is the > problem? node is bound to the boolean ptr is greater than or equal to > left and right. Except it's a SyntaxError because Python has no => operator. Carl signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 16/09/2015 18:41, Sven R. Kunze wrote: On 16.09.2015 19:33, Steven D'Aprano wrote: On Thu, 17 Sep 2015 01:40 am, Random832 wrote: "in" suggests a relationship between objects of different types (X and "something that can contain X") - all the other comparison operators are meant to work on objects of the same or similar types. `is` and the equality operators are intended to work on arbitrary objects, as are their inverses `is not` and inequality. And with operator overloading, < <= > and => could have any meaning you like: graph = a => b => c <= d <= e Sorry? What are you trying to do here? Typo I'd hazard a guess at, should be graph = a >= b >= c <= d <= e Assuming that I'm correct, graph is True if a is greater than or equal to b and b is greater than equal to c and c is less than or equal to d and d is less than or equal to e else False. So where is the problem? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Wed, Sep 16, 2015, at 16:38, Mark Lawrence wrote: > On 16/09/2015 18:41, Sven R. Kunze wrote: > > On 16.09.2015 19:33, Steven D'Aprano wrote: > >> And with operator overloading, < <= > and => could have any meaning you > >> like: > >> > >> graph = a => b => c <= d <= e > > > > Sorry? What are you trying to do here? > > Typo I'd hazard a guess at, should be graph = a >= b >= c <= d <= e > > Assuming that I'm correct, graph is True if a is greater than or equal > to b and b is greater than equal to c and c is less than or equal to d > and d is less than or equal to e else False. So where is the problem? Except in context, he was suggesting that they have a meaning other than "greater than or equal" and "less than or equal". (see "could have any meaning you like"). It seemed implied that he was suggesting there was some arrangement of operator overloads that could cause this statement to generate a directed graph with the structure shown. -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 16.09.2015 22:55, Random832 wrote: On Wed, Sep 16, 2015, at 16:38, Mark Lawrence wrote: On 16/09/2015 18:41, Sven R. Kunze wrote: On 16.09.2015 19:33, Steven D'Aprano wrote: And with operator overloading, < <= > and => could have any meaning you like: graph = a => b => c <= d <= e Sorry? What are you trying to do here? Typo I'd hazard a guess at, should be graph = a >= b >= c <= d <= e Assuming that I'm correct, graph is True if a is greater than or equal to b and b is greater than equal to c and c is less than or equal to d and d is less than or equal to e else False. So where is the problem? Except in context, he was suggesting that they have a meaning other than "greater than or equal" and "less than or equal". (see "could have any meaning you like"). It seemed implied that he was suggesting there was some arrangement of operator overloads that could cause this statement to generate a directed graph with the structure shown. Yes. Let's introduce ASCII art an way to describe graphs in Python. Best, Sven -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 16.09.2015 21:47, Grant Edwards wrote: On 2015-09-16, Sven R. Kunze wrote: On 16.09.2015 19:46, Grant Edwards wrote: On 2015-09-16, Steven D'Aprano wrote: node = left <= ptr => right Exactly. I've no clue what that means. ;) Modern art. ;) Ah, well I know that _that_ means: "I think it exemplifies the angst and conflict inherent in modern society". You can say that while standing in front of any piece of modern art, and most everybody will just nod. Try it. So right. But hey, it's a sport. ;) Btw. ASCII art is also art. So, why does Python not have ASCII art to define graphs and diagrams? Best, Sven -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 16/09/2015 21:39, Carl Meyer wrote: On 09/16/2015 02:29 PM, Mark Lawrence wrote: On 16/09/2015 18:53, Sven R. Kunze wrote: On 16.09.2015 19:39, Steven D'Aprano wrote: node = left <= ptr => right Wow. I have absolutely no idea what this is supposed to mean. Do you care to elaborate? Best, Sven Simple, straight forward easy to read bit of Python, where is the problem? node is bound to the boolean ptr is greater than or equal to left and right. Except it's a SyntaxError because Python has no => operator. Carl Yes, Steven has made this mistake elsewhere. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 16/09/2015 22:05, Sven R. Kunze wrote: On 16.09.2015 21:47, Grant Edwards wrote: On 2015-09-16, Sven R. Kunze wrote: On 16.09.2015 19:46, Grant Edwards wrote: On 2015-09-16, Steven D'Aprano wrote: node = left <= ptr => right Exactly. I've no clue what that means. ;) Modern art. ;) Ah, well I know that _that_ means: "I think it exemplifies the angst and conflict inherent in modern society". You can say that while standing in front of any piece of modern art, and most everybody will just nod. Try it. So right. But hey, it's a sport. ;) Btw. ASCII art is also art. So, why does Python not have ASCII art to define graphs and diagrams? Best, Sven Barry John art is also art. So, why does Python not have Barry John art to define graphs and diagrams? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 16.09.2015 23:30, Mark Lawrence wrote: Barry John art is also art. So, why does Python not have Barry John art to define graphs and diagrams? Too colorful for a grammer? -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging and deployment of standalone Python applications?
In a message of Wed, 16 Sep 2015 21:29:23 +0200, Kristian Rink writes: >Am 15.09.2015 um 08:59 schrieb [email protected]: >> >> https://docs.python.org/3/library/venv.html?highlight=venv#module-venv > >Thanks, this already is pretty close to what I need. Playing with this >and virtualenv, I figured out that this way it's pretty easily possible >to have isolated Python environments _locally_. However I failed to >package one of these environments and move it to, say, from my Ubuntu >development host to a remote Debian server, I end up with errors like >these while trying to run the Python off the environment on that host: > >/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found > >I bundled all the stuff in the virtualenv and also made sure to >dereference the symlinks in there. Are Python binaries so closely tied >to a particular Linux environment / distribution that what I am about to >do is impossible? Is there a "generic" Python for Linux binary that >works on all distributions, as things are for Java? > >TIA and all the best, >Kristian >-- >https://mail.python.org/mailman/listinfo/python-list Your problem is likely with the shared library search paths. Different distributions put them in different places. It's a real pain, and the reason why docker is getting more popular. According to http://www.eyrie.org/~eagle/notes/rpath.html there is a way to get around this by encoding the rpath in your application, but I cannot vouch for it personally. Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 16/09/2015 23:15, Sven R. Kunze wrote: On 16.09.2015 23:30, Mark Lawrence wrote: Barry John art is also art. So, why does Python not have Barry John art to define graphs and diagrams? Too colorful for a grammer? I'm not with you, sorry. Is "grammer" the US spelling of the UK "grammar"? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Thu, Sep 17, 2015 at 10:06 AM, Mark Lawrence wrote: > On 16/09/2015 23:15, Sven R. Kunze wrote: >> >> On 16.09.2015 23:30, Mark Lawrence wrote: >>> >>> Barry John art is also art. So, why does Python not have Barry John >>> art to define graphs and diagrams? >> >> >> Too colorful for a grammer? > > > I'm not with you, sorry. Is "grammer" the US spelling of the UK "grammar"? Certainly not. A grammer is something which grams. A gram is one thousandth of an SI unit. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: kivy editable multicolumn list
Às 08:44 de 15-09-2015, David Aldrich escreveu: >> Not sure if this is the place to ask about kivy ... > > Try the kivy users list here: > > https://groups.google.com/forum/#!forum/kivy-users Thanks for the link. -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 9/16/2015 5:53 PM, Chris Angelico wrote: On Thu, Sep 17, 2015 at 10:06 AM, Mark Lawrence wrote: On 16/09/2015 23:15, Sven R. Kunze wrote: On 16.09.2015 23:30, Mark Lawrence wrote: Barry John art is also art. So, why does Python not have Barry John art to define graphs and diagrams? Too colorful for a grammer? I'm not with you, sorry. Is "grammer" the US spelling of the UK "grammar"? Certainly not. A grammer is something which grams. A gram is one thousandth of an SI unit. My grammer used to say some pretty colorful things. :) Thankfully-my-daughter-the-english-teacher-won't-see-this-ly y'rs, Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Thu, 17 Sep 2015 03:44 am, Grant Edwards wrote: > On 2015-09-16, Steven D'Aprano wrote: >> On Thu, 17 Sep 2015 03:27 am, Grant Edwards wrote: >> >>> On 2015-09-16, Sven R. Kunze wrote: On 16.09.2015 18:57, Random832 wrote: > I think that chaining should be limited to: > > A) all operators are "=" > B) all operators are "is" >> >> [...] >>> I'm not all that sure A and B should be allowed. >> >> You can take `x == y == z` off me when you pry it from my cold, dead >> hands. > > Well, that case hadn't been mentioned yet. But, I agree that should be > added as case E and be allowed. I assumed that since we were talking about *operators* and *comparisons*, Random832 had merely typoed "=" when (s)he meant "==", since assignment = is neither an operator nor a comparison. But while we're at it, you can also take away chained assignments over my dead body -- and even then, I'll probably come back from the grave as vengeful spirit to wreck bloody retribution on all those responsible. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: kivy editable multicolumn list
Às 11:42 de 15-09-2015, Laura Creighton escreveu:
> In a message of Tue, 15 Sep 2015 03:31:49 +0100, Paulo da Silva writes:
...
>> Now I would like to change the background color the editable field.
>>
...
>
> I just hardcoded it like this:
>
> integers_dict = {str(i): {'text': str(i), 'is_selected': False}
> for i in range(100)}
>
> which I pasted out of http://kivy.org/docs/api-kivy.uix.listview.html
> 'Using an Item View Template'. This may have no relation to what you
> really want.
The example is closely based on an example that comes with kivy and is
supposed to run in the same directory. The fixtures there contain the
same as you hardcoded.
>
> you also need a line
> from kivy.graphics import Color, Rectangle
It's there. I just forgot to mention it.
>
> Then you change your class definition to be:
>
> class EditableLabel(ListItemLabel):
> def __init__(self,**kwargs):
> super(EditableLabel, self).__init__(**kwargs)
> self.bind(pos=self.redraw)
> self.bind(size=self.redraw)
>
> def redraw(self, *args):
> self.canvas.clear()
> with self.canvas:
> Color(.5,.5,.5)
> Rectangle(pos=self.pos,size=self.size)
>
This works but not as I expected. So it fixes the bug but the result I
got is not the pretended one.
I was trying to change the background color of the editable field.
That's the reason for the colored rectangle. But the rectangle overlaps
the text! So the entered text is hidden.
> I don't know why changing self.canvas.before: to self.canvas: in the redraw
> method was needed here. I expected self.canvas.before to be what was
> needed, but doesn't seem that way.
>
> If you don't clear the canvas first, in the redraw the results look very
> silly to me.
In both situations redraw is entered with wrong self.pos and self.size
values. So there are extra rectangles drawn at wrong places and sizes.
I can't understand why.
Changing self.canvas.before to self.canvas and inserting
self.canvas.clear() fixes the problem.
But as I said the drawn rectangle hides the label text.
Thank you Laura.
--
https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Thu, 17 Sep 2015 03:41 am, Sven R. Kunze wrote: > On 16.09.2015 19:33, Steven D'Aprano wrote: >> On Thu, 17 Sep 2015 01:40 am, Random832 wrote: >> >>> "in" suggests a relationship between objects of different types (X and >>> "something that can contain X") - all the other comparison operators are >>> meant to work on objects of the same or similar types. >> `is` and the equality operators are intended to work on arbitrary >> objects, as are their inverses `is not` and inequality. >> >> And with operator overloading, < <= > and => could have any meaning you >> like: >> >> graph = a => b => c <= d <= e >> > > Sorry? What are you trying to do here? Anything you like, I just made it up. That's the point: if a, b, etc have overloaded the operators, they could mean anything. The idea I vaguely had was that they constructed a graph, using => and <= as "arrows" so that the above would be equivalent to the graph: a -> b -> c <- d <- e (a to b, b to c; e to d, d also to c) -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Thu, 17 Sep 2015 03:47 am, Random832 wrote: > On Wed, Sep 16, 2015, at 13:33, Steven D'Aprano wrote: >> On Thu, 17 Sep 2015 01:40 am, Random832 wrote: >> >> > "in" suggests a relationship between objects of different types (X and >> > "something that can contain X") - all the other comparison operators >> > are meant to work on objects of the same or similar types. >> >> `is` and the equality operators are intended to work on arbitrary >> objects, >> as are their inverses `is not` and inequality. > > But they won't return *true* unless they're the same or similar types. So what? The intended purpose of `is` and `==` is not to return True. It is to perform a comparison which may return False, or True. >> And with operator overloading, < <= > and => could have any meaning you >> like: >> >> graph = a => b => c <= d <= e > > Are you suggesting that all objects concerned are a magical "graph node > object", the <= and [sic] => operators of which return "edge objects", > the and operator of which constructs a graph object containing all such > edges? That's *horrifying*. And won't actually work. We haven't actually > got an => operator, thankfully, and you can't overload 'and'. Ah yes, well, there is that. Oops. > I bet you could do it in C++ though. Almost certainly. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Thu, 17 Sep 2015 10:06 am, Mark Lawrence wrote: > On 16/09/2015 23:15, Sven R. Kunze wrote: >> On 16.09.2015 23:30, Mark Lawrence wrote: >>> Barry John art is also art. So, why does Python not have Barry John >>> art to define graphs and diagrams? >> >> Too colorful for a grammer? > > I'm not with you, sorry. Is "grammer" the US spelling of the UK > "grammar"? Mark, take a close look at Sven's name, and his email address. When your German is better than his English, then you can pick on his spelling. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Problem with lists
Em terça-feira, 15 de setembro de 2015 21:47:10 UTC-3, Chris Angelico escreveu:
> On Wed, Sep 16, 2015 at 10:29 AM, Rafael David wrote:
> > Oooohhh ... I think I got it! I'm assigning a reference to peca and not the
> > value itself! Thank you very much MRAB and C Smith for the enlightenment :)
>
> Right! That's how Python's assignment always works. You may find, in
> your case, that you can simply reassign peca={} every time through the
> loop. No copying necessary - just make yourself a new dict for each
> iteration.
>
> And you might be able to do the whole thing with a gigantic
> list/list/dict comprehension, but that may or may not be an
> improvement on your code :)
>
> ChrisA
Yes, got it. Thanks Chris!
Guys, this group rocks :)
--
https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Thu, 17 Sep 2015 10:06 am, Mark Lawrence wrote: > On 16/09/2015 23:15, Sven R. Kunze wrote: >> On 16.09.2015 23:30, Mark Lawrence wrote: >>> Barry John art is also art. So, why does Python not have Barry John >>> art to define graphs and diagrams? >> >> Too colorful for a grammer? > > I'm not with you, sorry. Is "grammer" the US spelling of the UK > "grammar"? Mark, take a close look at Sven's name, and his email address. When your German is better than his English, then you can pick on his spelling. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Context-aware return
On Sun, 13 Sep 2015 09:27 am, Ned Batchelder wrote: > On Thursday, September 10, 2015 at 8:44:01 PM UTC-4, Denis McMahon wrote: >> On Fri, 11 Sep 2015 03:54:14 +1000, Steven D'Aprano wrote: >> >> > If I did this thing, would people follow me down the street booing and >> > jeering and throwing things at me? >> >> Yes >> >> >>> x = func() >> >>> x >> >>> func() >> >>> print x == func() >> >>> assert x == func() >> >> Would you expect the last two calls to func() to return 999 or "Awesome"? >> Why? What is the material difference if any between interpreter (a) >> displaying the return value and (b) comparing the return value with >> another value. >> >> Debugging nightmare! > > I'll add my voice to the rising chorus condemning the very notion > of a function that behaves this way! > > Then, I'll give you an implementation (Python 2): Excellent! *cough* I mean, well, that's interesting. Of course no sane developer would ever use such a thing. Thanks to everyone who tried to discourage me from using this. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 2015-09-16 21:25, Mark Lawrence wrote: > Is it:- > > modern art == crap > > or > > modern art = crap Pretty sure they're both wrong... modern art < crap ;-) -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Wed, Sep 16, 2015, at 21:25, Steven D'Aprano wrote: > So what? The intended purpose of `is` and `==` is not to return True. It > is > to perform a comparison which may return False, or True. Yeah, but there's no point in doing a comparison unless you're doing it in a context where it *might* return true. Semantics matter. -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
Chris Angelico wrote: But are there _any_ comparison operators which are unchainable? If not, there's no reason to disallow 'in'; My problem is that I find it difficult to remember that Python considers 'in' to be a comparison operator. To me, comparison is something you do between things of the same kind, whereas 'in' is a relationship between things of different kinds. Calling it a comparison is like comparing apples and oranges. Or apples and baskets of apples, or something. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
Marko Rauhamaa wrote: "Sven R. Kunze" : But I agree more than this often helps confusion more than it helps clarity. I see what you did there. I see what you saw what he did there. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
Sven R. Kunze wrote: Btw. ASCII art is also art. So, why does Python not have ASCII art to define graphs and diagrams? Nowadays it would have to support Unicode art. Mustn't leave out all the world's non-English-speaking artists! -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
Mark Lawrence wrote: Is it:- modern art == crap or modern art = crap It's modern == art == crap, surely? -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
Chris Angelico wrote: Certainly not. A grammer is something which grams. A gram is one thousandth of an SI unit. Also, when ordering a hamburger in an SI-using country, instead of a quarter-pounder you need to ask for a 125-grammer. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
