Re: 3.4 on Windows ImportError: cannot import name 'IntEnum'
On 01/04/2014 08:35 PM, Mark Lawrence wrote: I first saw this when tring to run the command "py -3.4 -m ensurepip" which gave me this lot. Traceback (most recent call last): ... from enum import IntEnum ImportError: cannot import name 'IntEnum' Before I raise an issue on the bug tracker can another Windows user or two please confirm that this is a genuine problem and not my installation being corrupt or whatever. Hi, it works for me (Windows XP, 32) -- Marco Buttu -- https://mail.python.org/mailman/listinfo/python-list
Re: Blog "about python 3"
On Sat, Jan 4, 2014 at 6:27 PM, Steven D'Aprano wrote: > Fast is never more important than correct. It's just that sometimes you > might compromise a little (or a lot) on what counts as correct in order for > some speed. Is this statement even falsifiable? Can you conceive of a circumstance where someone has traded correctness for speed, but where one couldn't describe it that latter way? I can't. I think by definition you can always describe it that way, you just make "what counts as correctness" be "what the customer wants given the resources available". The conventional definition, however, is "what the customer wants, imagining that you have infinite resources". With just a little redefinition that seems reasonable, you can be made never to be wrong! I avoid making unfalsifiable arguments that aren't explicitly labeled as such. I try to reword them as, "I prefer to look at it as ..." -- it's less aggressive, which means people are more likely to really listen to what you have to say. It also doesn't pretend to be an argument when it isn't. -- Devin -- https://mail.python.org/mailman/listinfo/python-list
Re: print range in python3.3
On 05/01/2014 07:38, luofeiyu wrote: range(1,10) range(1, 10) print(range(1,10)) range(1, 10) how can i get 1,2,3,4,5,6,7,8,9 in python3.3 ? for i in range(1,10): print(i, end=',') print() I hope you can cope with the comma at EOL :) -- 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: 3.4 on Windows ImportError: cannot import name 'IntEnum'
On 04/01/2014 19:35, Mark Lawrence wrote: Raised an issue anyway and then found a file caused enum.py. Whoops :( -- 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: django question
Hi, Tim, On Sat, Jan 4, 2014 at 5:37 PM, Tim Chase wrote: > On 2014-01-04 15:30, Igor Korot wrote: >> Does anybody here use django? > > Yes. However there's also a Django-users mailing list[1] for > Django-specific questions. Folks there are friendly & helpful. Thank you for that. I didn't look too close on the django web site. ;-) > >> Is it possible to display a data grid table with django? > > The short answer is yes. > >> Basically I am looking for displaying a data from the db table on >> the web interface thru django or some other web interface. > > While I prefer Django for larger projects, for a lighter-weight > project such as what you describe, I'd be tempted to go with > something a little more light-weight unless you need additional > interactivity. I've recently been impressed with Bottle[2] for a > small & clean web framework. CherryPy comes somewhere in the middle, > but I can't say it met my needs/wants on the last project where it > was chosen (mostly in the documentation department, but it's hard to > beat Django's stellar docs). And thank you for those points as well. This piece will be for the proof of concept, which later on will go to much bigger application with reporting, plotting and different types of data presentation. Now would it be easy to switch from either on of them to django? Or is there a better choice for the main application? Thank you. > > -tkc > > [1] > http://groups.google.com/group/django-users > > [2] > http://bottlepy.org/ > > > > > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
should error class be defined in the class it logically belongs?
Let's say we have in livestocks.py
# livestocks.py stores all livestock classes
class cat()
...
class Dog()
...
class CanineDistemper(Exception)
'''
<<< Buddy = Dog(name = "Buddy")
<<< raise CanineDistemper(Buddy) # horrible test code!
'''
def __init__(self, dog)
self.owner = dog # a specific dog
def __str__(self)
return "{} has had Canine Distemper".format(self.canine)
One would naturally wonder, since
1. by definition only a canine (a dog) can have CanineDistemper, and
2. in no case can CanineDistemper be raised without specifying which object
(canine) is having the problem,
Thus, CanineDistemper is an integral part of Canine class, and one is
naturally tempted to defined CanineDistemper inside Canine class.
Let some experienced OOP guy explain a bit if this line of thinking is
logical, or impratical. Thanks!
--
https://mail.python.org/mailman/listinfo/python-list
Re: should error class be defined in the class it logically belongs?
Zhang Weiwu writes: > 1. by definition only a canine (a dog) can have CanineDistemper, and > 2. in no case can CanineDistemper be raised without specifying which > object (canine) is having the problem, > > Thus, CanineDistemper is an integral part of Canine class You haven't supported that claim, and it doesn't follow from the above premises. It's not that CanineDistemper is integral to Canine, but merely that CanineDistemper is conceptually related to Canine. > and one is naturally tempted to defined CanineDistemper inside Canine > class. I'd recommend you decline that temptation. Exception classes should be defined at module level, because it makes for more readable tracebacks and there's not much to be gained from defining exception classes inside other classes. A class is a distinct namespace, and it will be more difficult for users of your module to make use of CanineDistemper if they have to reach down into the implementation of Canine in order to get at that exception class. > Let some experienced OOP guy explain a bit if this line of thinking is > logical, or impratical. Thanks! I think it's illogical, because of the way you've laid out your logic; the conclusion you assert doesn't follow from your premises. Even if you contrived a different situation where it would be logical, I think it is almost surely going to be impractical. -- \“Of course, everybody says they're for peace. Hitler was for | `\ peace. Everybody is for peace. The question is: what kind of | _o__)peace?” —Noam Chomsky, 1984-05-14 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: python finance
On Thursday, January 2, 2014 11:37:59 AM UTC, d ss wrote: > dailystockselect.com needs a couple of talented python people for the > development and implementation of new trading strategies. it may be also some > pythonic design change for the displayed figures now the web app consists of > 1 of the 8 conceived strategies. contact us at the email on the website for > more details > Samir Please this is a spam.. I've reported this as a spam. I wish everyone who sees this also reports it as spam to get the user bannned. This way GG will be a wee bit better Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: print range in python3.3
On Jan 5, 2014 1:04 AM, "Mark Lawrence" wrote: > > On 05/01/2014 07:38, luofeiyu wrote: > > range(1,10) >> >> range(1, 10) > > print(range(1,10)) >> >> range(1, 10) >> >> how can i get 1,2,3,4,5,6,7,8,9 in python3.3 ? >> > > for i in range(1,10): > print(i, end=',') > print() > > I hope you can cope with the comma at EOL :) print(*range(1, 10), sep=',') -- https://mail.python.org/mailman/listinfo/python-list
Dos cursor and input management.
Hi all. I am after a module that manages keyboard input. I am aware of raw_input for python 2.x and input for 3.x. They don't quite achieve what I want. I want to except a single key without printing it to the screen and then the key would perform an action. Sudo code: print line of text wait for key press If key press equals delete line. Delete list element. else if key press equals edit display line for interactive edit. else move to next line The module must work under dos for now. Eventually Mac. Sean -- https://mail.python.org/mailman/listinfo/python-list
Re: Blog "about python 3"
Le dimanche 5 janvier 2014 03:54:29 UTC+1, Chris Angelico a écrit :
> On Sun, Jan 5, 2014 at 1:41 PM, Steven D'Aprano
>
> wrote:
>
> > wxjmfa...@gmail.com wrote:
>
> >
>
> >> The very interesting aspect in the way you are holding
>
> >> unicodes (strings). By comparing Python 2 with Python 3.3,
>
> >> you are comparing utf-8 with the the internal "representation"
>
> >> of Python 3.3 (the flexible string represenation).
>
> >
>
> > This is incorrect. Python 2 has never used UTF-8 internally for Unicode
>
> > strings. In narrow builds, it uses UTF-16, but makes no allowance for
>
> > surrogate pairs in strings. In wide builds, it uses UTF-32.
>
>
>
> That's for Python's unicode type. What Robin said was that they were
>
> using either a byte string ("str") with UTF-8 data, or a Unicode
>
> string ("unicode") with character data. So jmf was right, except that
>
> it's not specifically to do with Py2 vs Py3.3.
>
>
Yes, the key point is the preparation of the "unicode
text" for the PDF producer.
This is at this level the different flavours of Python
may be relevant.
I see four possibilites, I do not know what
the PDF producer API is expecting.
- Py2 with utf-8 byte string (ev. utf-16, utf-32)
- Py2 with its internal unicode
- Py3.2 with its internal unicode
- Py3.3 with its internal unicode
jmf
--
https://mail.python.org/mailman/listinfo/python-list
Re: Blog "about python 3"
On 31.12.2013 10:53, Steven D'Aprano wrote: > Mark Lawrence wrote: > >> http://blog.startifact.com/posts/alex-gaynor-on-python-3.html. > > I quote: > > "...perhaps a brave group of volunteers will stand up and fork Python 2, and > take the incremental steps forward. This will have to remain just an idle > suggestion, as I'm not volunteering myself." > > I expect that as excuses for not migrating get fewer, and the deadline for > Python 2.7 end-of-life starts to loom closer, more and more haters^W > Concerned People will whine about the lack of version 2.8 and ask for > *somebody else* to fork Python. > > I find it, hmmm, interesting, that so many of these Concerned People who say > that they're worried about splitting the Python community[1] end up > suggesting that we *split the community* into those who have moved forward > to Python 3 and those who won't. Exactly. I don't know what exactly their problem is. I've pushed the migration of *large* projects at work to Python3 when support was pretty early and it really wasn't a huge deal. Specifically because I love pretty much every single aspect that Python3 introduced. The codec support is so good that I've never seen anything like it in any other programming language and then there's the tons of beautiful changes (div/intdiv, functools.lru_cache, print(), datetime.timedelta.total_seconds(), int.bit_length(), bytes/bytearray). Regards, Joe -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa -- https://mail.python.org/mailman/listinfo/python-list
Re: Blog "about python 3"
Devin Jeanpierre wrote:
> On Sat, Jan 4, 2014 at 6:27 PM, Steven D'Aprano
> wrote:
>> Fast is never more important than correct. It's just that sometimes you
>> might compromise a little (or a lot) on what counts as correct in order
>> for some speed.
>
> Is this statement even falsifiable? Can you conceive of a circumstance
> where someone has traded correctness for speed, but where one couldn't
> describe it that latter way? I can't.
Every time some programmer "optimises" a piece of code (or, more often,
*thinks* they have optimised it) which introduces bugs into the software,
that's a case where somebody has traded correctness for speed where my
statement doesn't apply. Sometimes the response to the subsequent bug
report is "will not fix", and a retroactive change in the software
requirements. ("Oh, did we say that indexing a string would return a
character? We meant it would return a character, so long as the string only
includes no Unicode characters in the astral planes.") Sometimes it is to
revert the optimisation or otherwise fix the bug.
I accept that there is sometimes a fine line here. I'm assuming that
software applications have their requirements fully documented, which in
the real world is hardly ever the case. Although, even if the requirements
aren't always written down, often they are implicitly understood. (Although
it gets very interesting when the users' understanding and the developers'
understanding is different.)
Take as an example this "torture test" for a mathematical sum function,
where the built-in sum() gets the wrong answer but math.fsum() gets it
right:
py> from math import fsum
py> values = [1e12, 0.0001, -1e12, 0.0001]*1
py> fsum(values)
2.0
py> sum(values)
2.4413841796875
Here's another example of the same thing, just to prove it's not a fluke:
py> values = [1e17, 1, 1, -1e17]
py> fsum(values)
2.0
py> sum(values)
0.0
The reason for the different results is that fsum() tries hard to account
for intermediate rounding errors and sum() does not. If you benchmark the
two functions, you'll find that sum() is significantly faster than fsum. So
the question to be asked is, does sum() promise to calculate floating point
sums accurately? If so, then this is a bug, probably introduced by the
desire for speed. But in fact, sum() does not promise to calculate floating
point sums accurately. What it promises to do is to calculate the
equivalent of a + b + c + ... for as many values as given, and that's
exactly what it does. Conveniently, that's faster than fsum(), and usually
accurate enough for most uses.
Is sum() buggy? No, of course not. It does what it promises, it's just that
what it promises to do falls short of "calculate floating point summations
to high accuracy".
Now, here's something which *would* be a bug, if sum() did it:
class MyInt(int):
def __add__(self, other):
return MyInt(super(MyInt, self).__add__(other))
def __radd__(self, other):
return MyInt(super(MyInt, self).__radd__(other))
def __repr__(self):
return "MyInt(%d)" % self
Adding a zero MyInt to an int gives a MyInt:
py> MyInt(0) + 23
MyInt(23)
so sum() should do the same thing. If it didn't, if it optimised away the
actual addition because "adding zero to a number can't change anything", it
would be buggy. But in fact, sum() does the right thing:
py> sum([MyInt(0), 23])
MyInt(23)
> I think by definition you can
> always describe it that way, you just make "what counts as
> correctness" be "what the customer wants given the resources
> available".
Not quite. "Correct" means "does what the customer wants". Or if there is no
customer, it's "does what you say it will do".
How do we tell when software is buggy? We compare what it actually does to
the promised behaviour, or expected behaviour, and if there is a
discrepancy, we call it a bug. We don't compare it to some ideal that
cannot be met. A bug report that math.pi does not have infinite number of
decimal places would be closed as "Will Not Fix".
Likewise, if your customer pays you to solve the Travelling Salesman Problem
exactly, even if it takes a week to calculate, then nothing short of a
program that solves the Travelling Salesman Problem exactly will satisfy
their requirements. It's no good telling the customer that you can
calculate a non-optimal answer twenty times faster if they want the actual
optimal answer.
(Of course, you may try to persuade them that they don't really need the
optimal solution, or that they cannot afford it, or that you cannot deliver
and they need to compromise.)
> The conventional definition, however, is "what the
> customer wants, imagining that you have infinite resources".
I don't think the resources really come into it. At least, certainly not
*infinite* resources. fsum() doesn't require infinite resources to
calculate floating point summations to high accuracy. An even more accurate
(but even slower) version would convert each float into a Fraction, then
add
Re: Blog "about python 3"
On Sun, Jan 5, 2014 at 11:28 PM, Steven D'Aprano wrote: > - "The Unix 'locate' command doesn't do a live search of the file > system because that would be too slow, it uses a snapshot of the > state of the file system." > > > Is locate buggy because it tells you what files existed the last time the > updatedb command ran, instead of what files exist right now? No, of course > not. locate does exactly what it promises to do. Even more strongly: We say colloquially that Google, DuckDuckGo, etc, etc, are tools for "searching the web". But they're not. They're tools for *indexing* the World Wide Web, and then searching that index. It's plausible to actually search your file system (and there are times when you want that), but completely implausible to search the (F or otherwise) web. We accept the delayed appearance of a page in the search results because we want immediate results, no waiting a month to find anything! So the difference between what's technically promised and what's colloquially described may be more than just concealing bugs - it may be the vital difference between uselessness and usefulness. And yet we like the handwave. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Blog "about python 3"
On 31/12/2013 09:53, Steven D'Aprano wrote: Mark Lawrence wrote: http://blog.startifact.com/posts/alex-gaynor-on-python-3.html. I quote: "...perhaps a brave group of volunteers will stand up and fork Python 2, and take the incremental steps forward. This will have to remain just an idle suggestion, as I'm not volunteering myself." I expect that as excuses for not migrating get fewer, and the deadline for Python 2.7 end-of-life starts to loom closer, more and more haters^W Concerned People will whine about the lack of version 2.8 and ask for *somebody else* to fork Python. Should the "somebody else" fork Python, in ten (ish) years time the Concerned People will be complaining that they can't port their code to Python 4 and will "somebody else" please produce version 2.9. -- 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
"More About Unicode in Python 2 and 3"
http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ Please don't shoot the messenger :) -- 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: "More About Unicode in Python 2 and 3"
On 1/5/14 8:14 AM, Mark Lawrence wrote: http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ Please don't shoot the messenger :) With all of the talk about py 2 vs. py3 these days, this is the blog post that I think deserves the most real attention. I haven't had to do the kind of coding that Armin is talking about, but I've heard more than one person talk about the difficulty of it in Python 3. If anyone wants Python 3 uptake improved, the best thing would be to either explain to Armin how he missed the easy way to do what he wants (seems unlikely), or advocate to the core devs why they should change things to improve this situation. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
On Mon, Jan 6, 2014 at 12:14 AM, Mark Lawrence wrote:
> http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/
>
> Please don't shoot the messenger :)
Most of that is tiresome reiterations of the same arguments ("It
worked fine, there were just a few problems" - which means that you
haven't thought through text vs bytes properly; the switch to Py3
highlights a problem that was already there, which means that Py3
showed up what was already a problem - sounds a bit like Romans 7 to
me), plus complaints that have been heard elsewhere, like the
encode/decode methods and the removal of codecs that aren't
str<->bytes. (Don't know if that one will ever be resolved, but it's
not enough to say that Python 3 "got it wrong". As we've seen from
3.3, there has been a progressive improvement in compatibility between
Py2 and Py3. Maybe 3.5 will recreate some of these things people are
moaning about the lack of, which would then prove that the Py3 model
isn't fundamentally flawed by their loss. Anyhow.)
But this bit looks odd:
"""
For instance passing a urllib request object to Flask's JSON parse
function breaks on Python 3 but works on Python 2 as a result of this:
>>> from urllib.request import urlopen
>>> r = urlopen('https://pypi.python.org/pypi/Flask/json')
>>> from flask import json
>>> json.load(r)
Traceback (most recent call last):
File "decoder.py", line 368, in raw_decode
StopIteration
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "", line 1, in
ValueError: No JSON object could be decoded
"""
Why is a StopIteration bubbling up? (I don't have Flask, so I can't
verify this.) Is it as simple as "this should be raising from None",
or is there something else going on?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
On Mon, Jan 6, 2014 at 12:22 AM, Ned Batchelder wrote: > If anyone wants Python 3 uptake improved, the best thing would be to either > explain to Armin how he missed the easy way to do what he wants (seems > unlikely), or advocate to the core devs why they should change things to > improve this situation. I'm not sure that there is an "easy way". See, here's the deal. If all your data is ASCII, you can shut your eyes to the difference between bytes and text and Python 2 will work perfectly for you. Then some day you'll get a non-ASCII character come up (or maybe you'll get all of Latin-1 "for free" and it's when you get a non-Latin-1 character - same difference), and you start throwing in encode() and decode() calls in places. But you feel like you're fixing little problems with little solutions, so it's no big deal. Making the switch to Python 3 forces you to distinguish bytes from text, even when that text is all ASCII. Suddenly that's a huge job, a huge change through all your code, and it's all because of this switch to Python 3. The fact that you then get the entire Unicode range "for free" doesn't comfort people who are dealing with URLs and are confident they'll never see anything else (if they *do* see anything else, it's a bug at the far end). Maybe it's the better way, but like trying to get people to switch from MS Word onto an open system, it's far easier to push for Open Office than for LaTeX. Getting your head around a whole new way of thinking about your data is work, and people want to be lazy. (That's not a bad thing, by the way. Laziness means schedules get met.) So what can be done about it? Would it be useful to have a type that represents an ASCII string? (Either 'bytes' or something else, it doesn't matter what.) I'm inclined to say no, because as of the current versions, encoding/decoding UTF-8 has (if I understand correctly) been extremely optimized in the specific case of an all-ASCII string; so the complaint that there's no "string formatting for bytes" could be resolved by simply decoding to str, then encoding to bytes. I'd look on that as having two costs, a run-time performance cost and a code readability cost, and then look at reducing each of them - but without blurring the bytes/text distinction. Yes, that distinction is a cost. It's like any other mental cost, and it just has to be paid. The only way to explain it is that Py2 has the "cost gap" between ASCII (or Latin-1) and the rest of Unicode, but Py3 puts that cost gap before ASCII, and then gives you all of Unicode for the same low price (just $19.99 a month, you won't even notice the payments!). Question, to people who have large Py2 codebases that manipulate mostly-ASCII text. How bad would it be to your code to do this: # Py2: build a URL url = "http://my.server.name/%s/%s"; % (path, fn) # Py3: build a URL as bytes def B(s): if isinstance(s, str): return s.encode() return s.decode() url = B(B(b"http://my.server.name/%s/%s";) % (path, fn)) ? This little utility function lets you do the formatting as text (let's assume the URL pattern comes from somewhere else, or you'd just strip off the b'' prefix), while still mostly working with bytes. Is it an unacceptable level of code clutter? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Blog "about python 3"
Johannes Bauer, 05.01.2014 13:14: > I've pushed the > migration of *large* projects at work to Python3 when support was pretty > early and it really wasn't a huge deal. I think there are two sides to consider. Those who can switch their code base to Py3 and be happy (as you did, apparently), and those who cannot make the switch but have to keep supporting Py2 until 'everyone' else has switched, too. The latter is a bit more work generally and applies mostly to Python packages on PyPI, i.e. application dependencies. There are two ways to approach that problem. One is to try convincing people that "Py3 has failed, let's stop migrating more code before I have to start migrating mine", and the other is to say "let's finish the migration and get it done, so that we can finally drop Py2 support in our new releases and clean up our code again". As long as we stick in the middle and keep the status quo, we keep the worst of both worlds. And, IMHO, pushing loudly for a Py2.8 release provides a very good excuse for others to not finish their part of the migration, thus prolonging the maintenance burden for those who already did their share. Maybe a couple of major projects should start dropping their Py2 support, just to make their own life easier and to help others in taking their decision, too. (And that's me saying that, who maintains two major projects that still have legacy support for Py2.4 ...) Stefan -- https://mail.python.org/mailman/listinfo/python-list
Re: Blog "about python 3"
Le samedi 4 janvier 2014 23:46:49 UTC+1, Terry Reedy a écrit : > On 1/4/2014 2:10 PM, wxjmfa...@gmail.com wrote: > > > Le samedi 4 janvier 2014 15:17:40 UTC+1, Chris Angelico a écrit : > > > > >> any, and Python has only one, idiot like jmf who completely > > > > Chris, I appreciate the many contributions you make to this list, but > > that does not exempt you from out standard of conduct. > > > > >> misunderstands what's going on and uses microbenchmarks to prove > > >> obscure points... and then uses nonsense to try to prove... uhh... > > > > Troll baiting is a form of trolling. I think you are intelligent enough > > to know this. Please stop. > > > > > I do not mind to be considered as an idiot, but > > > I'm definitively not blind. > > > > > > And I could add, I *never* saw once one soul, who is > > > explaining what I'm doing wrong in the gazillion > > > of examples I gave on this list. > > > > If this is true, it is because you have ignored and not read my > > numerous, relatively polite posts. To repeat very briefly: > > > > 1. Cherry picking (presenting the most extreme case as representative). > > > > 2. Calling space saving a problem (repeatedly). > > > > 3. Ignoring bug fixes. > > > > 4. Repetition (of the 'gazillion example' without new content). > > > > Have you ever acknowledged, let alone thank people for, the fix for the > > one bad regression you did find. The FSR is still a work in progress. > > Just today, Serhiy pushed a patch speeding up the UTF-32 encoder, after > > previously speeding up the UTF-32 decoder. > > > > -- My examples are ONLY ILLUSTRATING, this FSR is wrong by design, can be on the side of memory, performance, linguistic or even typography. I will not refrain you to waste your time in adjusting bytes, if the problem is not on that side. jmf -- https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
On Sun, 05 Jan 2014 08:22:38 -0500 Ned Batchelder wrote: > On 1/5/14 8:14 AM, Mark Lawrence wrote: > > http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ > > > > Please don't shoot the messenger :) > > > > With all of the talk about py 2 vs. py3 these days, this is the blog > post that I think deserves the most real attention. I haven't had to do > the kind of coding that Armin is talking about, but I've heard more than > one person talk about the difficulty of it in Python 3. > > If anyone wants Python 3 uptake improved, the best thing would be to > either explain to Armin how he missed the easy way to do what he wants > (seems unlikely), or advocate to the core devs why they should change > things to improve this situation. Sometimes the best way to "advocate to the core devs" is to do part of the work, though. There are several people arguing for %-formatting or .format() on bytes, but that still lacks a clear description of which formatting codes would be supported, with which semantics. (see e.g. http://bugs.python.org/issue3982) As for the rest of Armin's rant, well, it's a rant. "In some cases Python 3 is a bit less practical than Python 2" doesn't equate to "Python 3 is broken and 2.8 should be released instead". Regards Antoine. -- https://mail.python.org/mailman/listinfo/python-list
Re: Blog "about python 3"
On 1/5/14 9:23 AM, wxjmfa...@gmail.com wrote: Le samedi 4 janvier 2014 23:46:49 UTC+1, Terry Reedy a écrit : On 1/4/2014 2:10 PM, wxjmfa...@gmail.com wrote: I do not mind to be considered as an idiot, but I'm definitively not blind. And I could add, I *never* saw once one soul, who is explaining what I'm doing wrong in the gazillion of examples I gave on this list. If this is true, it is because you have ignored and not read my numerous, relatively polite posts. To repeat very briefly: 1. Cherry picking (presenting the most extreme case as representative). 2. Calling space saving a problem (repeatedly). 3. Ignoring bug fixes. 4. Repetition (of the 'gazillion example' without new content). Have you ever acknowledged, let alone thank people for, the fix for the one bad regression you did find. The FSR is still a work in progress. Just today, Serhiy pushed a patch speeding up the UTF-32 encoder, after previously speeding up the UTF-32 decoder. -- My examples are ONLY ILLUSTRATING, this FSR is wrong by design, can be on the side of memory, performance, linguistic or even typography. JMF: this has been pointed out to you time and again: the flexible string representation is not wrong. To show that it is wrong, you would have to demonstrate some semantic of Unicode that is violated. You have never done this. You've picked pathological cases and shown micro-timing output, and memory usage. The Unicode standard doesn't promise anything about timing or memory use. The FSR makes a trade-off of time and space. Everyone but you considers it a good trade-off. I don't think you are showing real use cases, but if they are, I'm sorry that your use-case suffers. That doesn't make the FSR wrong. The most accurate statement is that you don't like the FSR. That's fine, you're entitled to your opinion. You say the FSR is wrong linguistically. This can't be true, since an FSR Unicode string is indistinguishable from an internally-UTF-32 Unicode string, and no, memory use or timings are irrelevant when discussing the linguistic performance of a Unicode string. You've also said that the internal representation of the FSR is incorrect because of encodings somehow. Encodings have nothing to do with the internal representation of a Unicode string, they are for interchanging data. You seem to know a lot about Unicode, but when you make this fundamental mistake, you call all of your expertise into question. To re-iterate what you are doing wrong: 1) You continue to claim things that are not true, and that you have never substantiated. 2) You paste code samples without accompanying text that explain what you are trying to demonstrate. 3) You ignore refutations that disprove your points. These are all the behaviors of a troll. Please stop. If you want to discuss the details of Unicode implementations, I'd welcome an offlist discussion, but only if you will approach it honestly enough to leave open the possibility that you are wrong. I know I would be glad to learn details of Unicode that I have missed, but so far you haven't provided any. --Ned. I will not refrain you to waste your time in adjusting bytes, if the problem is not on that side. jmf -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Blog "about python 3"
In article <52c94fec$0$29973$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano wrote: > How do we tell when software is buggy? We compare what it actually does to > the promised behaviour, or expected behaviour, and if there is a > discrepancy, we call it a bug. We don't compare it to some ideal that > cannot be met. A bug report that math.pi does not have infinite number of > decimal places would be closed as "Will Not Fix". That's because it is inherently impossible to "fix" that. But lots of bug reports legitimately get closed with "Will Not Fix" simply because the added value from fixing it doesn't justify the cost (whether in terms of development effort, or run-time resource consumption). Go back to the package sorting example I gave. If the sorting software mis-reads the address and sends my package to Newark instead of New York by mistake, that's clearly a bug. Presumably, it's an error which could be eliminated (or, at least, the rate of occurrence reduced) by using a more sophisticated OCR algorithm. But, if those algorithms take longer to run, the overall expected value of implementing the bug fix software may well be negative. In the real world, nobody cares if software is buggy. They care that it provides value. -- https://mail.python.org/mailman/listinfo/python-list
Struggling with an anchor in my hands
SO, I'm still trying to make that tkinter code. I've come far enough, but I now should place the elements in the window. But I'm having problems with anchor. No matter how I use it, it always goes to the SW part. I want them to go to the NW part. Any help please? I can provide any needed info. -- https://mail.python.org/mailman/listinfo/python-list
Re: Blog "about python 3"
In article , Chris Angelico wrote: > On Sun, Jan 5, 2014 at 2:20 PM, Roy Smith wrote: > > I've got a new sorting algorithm which is guaranteed to cut 10 seconds > > off the sorting time (i.e. $0.10 per package). The problem is, it makes > > a mistake 1% of the time. > > That's a valid line of argument in big business, these days, because > we've been conditioned to accept low quality. But there are places > where quality trumps all, and we're happy to pay for that. Allow me to > expound two examples. > > 1) Amazon > > http://www.amazon.com/exec/obidos/ASIN/1782010165/evertype-20 > > I bought this book a while ago. It's about the size of a typical > paperback. It arrived in a box too large for it on every dimension, > with absolutely no packaging. I complained. Clearly their algorithm > was: "Most stuff will get there in good enough shape, so people can't > be bothered complaining. And when they do complain, it's cheaper to > ship them another for free than to debate with them on chat." You're missing my point. Amazon's (short-term) goal is to increase their market share by undercutting everybody on price. They have implemented a box-packing algorithm which clearly has a bug in it. You are complaining that they failed to deliver your purchase in good condition, and apparently don't care. You're right, they don't. The cost to them to manually correct this situation exceeds the value. This is one shipment. It doesn't matter. You are one customer, you don't matter either. Seriously. This may be annoying to you, but it's good business for Amazon. For them, fast and cheap is absolutely better than correct. I'm not saying this is always the case. Clearly, there are companies which have been very successful at producing a premium product (Apple, for example). I'm not saying that fast is always better than correct. I'm just saying that correct is not always better than fast. -- https://mail.python.org/mailman/listinfo/python-list
Re: Dos cursor and input management.
On Sun, 05 Jan 2014 20:25:11 +1100, Sean Murphy wrote: > The module must work under dos for now. Eventually Mac. Do you mean a windows command line terminal window, or some *nix shell? As far as I know, dos as an operating system hasn't been around since version 6.22 or thereabouts, although I believe ms windows provides a dos shell like interface on top of the windows os. I'm not aware that any version of python is supported on dos, but I may be wrong, there may be some 15 year old hardware running dos somewhere that also has a working python install. I associate dos with machines of the pre-pentium era, although I suspect that might not be quite accurate either. -- Denis McMahon, denismfmcma...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Blog "about python 3"
On Mon, Jan 6, 2014 at 3:34 AM, Roy Smith wrote:
> Amazon's (short-term) goal is to increase their market share by
> undercutting everybody on price. They have implemented a box-packing
> algorithm which clearly has a bug in it. You are complaining that they
> failed to deliver your purchase in good condition, and apparently don't
> care. You're right, they don't. The cost to them to manually correct
> this situation exceeds the value. This is one shipment. It doesn't
> matter.
If it stopped there, it would be mildly annoying ("1% of our shipments
will need to be replaced, that's a 1% cost for free replacements").
The trouble is that they don't care about the replacement either, so
it's really that 100% (or some fairly large proportion) of their
shipments will arrive with some measure of damage, and they're hoping
that their customers' threshold for complaining is often higher than
the damage sustained. Which it probably is, a lot of the time.
> You are one customer, you don't matter either. Seriously.
> This may be annoying to you, but it's good business for Amazon. For
> them, fast and cheap is absolutely better than correct.
But this is the real problem, business-wise. Can you really run a
business by not caring about your customers? (I also think it's pretty
disappointing that a business like Amazon can't just toss in some
bubbles, or packing peanuts (what we call "trucks" for hysterical
raisins), or something. It's not that hard to have a machine just blow
in some sealed air before the box gets closed... surely?) Do they have
that much of a monopoly, or that solid a customer base, that they're
happy to leave *everyone* dissatisfied? We're not talking about 1%
here. From the way the cust svc guy was talking, I get the impression
that they do this with all parcels.
And yet I can't disagree with your final conclusion. Empirical
evidence goes against my incredulous declaration that "surely this is
a bad idea" - according to XKCD 1165, they're kicking out nearly a
cubic meter a *SECOND* of packages. That's fairly good evidence that
they're doing something that, whether it be right or wrong, does fit
with the world's economy. Sigh.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Dos cursor and input management.
On 05/01/2014 09:25, Sean Murphy wrote: Hi all. I am after a module that manages keyboard input. I am aware of raw_input for python 2.x and input for 3.x. They don't quite achieve what I want. I want to except a single key without printing it to the screen and then the key would perform an action. Sudo code: print line of text wait for key press If key press equals delete line. Delete list element. else if key press equals edit display line for interactive edit. else move to next line The module must work under dos for now. Eventually Mac. Sean I think you're looking for something like this https://github.com/jmcb/python-pdcurses -- 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: Blog "about python 3"
Chris Angelico wrote: > Can you really run a business by not caring about your customers? http://snltranscripts.jt.org/76/76aphonecompany.phtml -- https://mail.python.org/mailman/listinfo/python-list
Re: Using multiple ORMs? - And SQLalchemy vs Pony vs Peewee vs stdnet vs …
> Thanks for all suggestions, Two essential criteria: If an ORM only allows 1:1 mapping between classes and tables à la "active record", then it's entirely pointless. And if an ORM allows only surrogate keys, then its developers don't have a clue of databases or they don't give a darn. Or both. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
gotta love radio buttons
So, I'm having this radio button issue in tkinter: First I assign the IntVar: var = [] while i < self.something: var.append(IntVar()) i += 2 Later on I use them, but I get this error: for r in var: helper = var[r].get() self.something_else[helper] += 1 Then, this happens: Traceback (most recent call last): File "F:\Portable Python 3.2.5.1\App\lib\tkinter\__init__.py", line 1456, in __call__ return self.func(*args) File "(Not giving this)", line 26, in submit_data helper = var[r].get() TypeError: list indices must be integers, not IntVar I'm willing to give additional info. Thank you in advance. -- https://mail.python.org/mailman/listinfo/python-list
Re: gotta love radio buttons
In article <8dca57e8-8258-4020-9788-987af332b...@googlegroups.com>, eneskri...@gmail.com wrote: I don't use tkinter, but here's what I can figure out from looking at your code and http://effbot.org/tkinterbook/variable.htm > var = [] > while i < self.something: > var.append(IntVar()) > i += 2 At this point, var is a list of IntVar instances. > for r in var: > helper = var[r].get() > self.something_else[helper] += 1 You are iterating over the element of var, so each time through the loop, r is an IntVar instance. But, you're using r to index a list in > helper = var[r].get() That's what > TypeError: list indices must be integers, not IntVar means. I suspect what you want is to retrieve the integer value from r, and use that as the index: > helper = var[r.get()] but without knowing more about your code, that's just a guess. At a deeper level, however, there's something that fundamentally doesn't make sense here. You are iterating over the values in var, then using each value as an index again. That's not *wrong*, but it seems unlikely to be what you want. -- https://mail.python.org/mailman/listinfo/python-list
Re: gotta love radio buttons
On 1/5/14 1:18 PM, eneskri...@gmail.com wrote: So, I'm having this radio button issue in tkinter: First I assign the IntVar: var = [] while i < self.something: var.append(IntVar()) i += 2 Later on I use them, but I get this error: for r in var: helper = var[r].get() self.something_else[helper] += 1 Then, this happens: Traceback (most recent call last): File "F:\Portable Python 3.2.5.1\App\lib\tkinter\__init__.py", line 1456, in __call__ return self.func(*args) File "(Not giving this)", line 26, in submit_data helper = var[r].get() TypeError: list indices must be integers, not IntVar I'm willing to give additional info. Thank you in advance. This isn't about radio buttons, it's about how for loops work. I think you want: for r in var: helper = r.get() The iteration variable in a for loop (r in this case) takes on the values of the elements of the list, not the indexes of the elements. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: gotta love radio buttons
eneskri...@gmail.com wrote: > So, I'm having this radio button issue in tkinter: > First I assign the IntVar: > var = [] > while i < self.something: > var.append(IntVar()) > i += 2 > Later on I use them, but I get this error: > for r in var: > helper = var[r].get() > self.something_else[helper] += 1 > Then, this happens: > Traceback (most recent call last): > File "F:\Portable Python 3.2.5.1\App\lib\tkinter\__init__.py", line > 1456, in __call__ > return self.func(*args) > File "(Not giving this)", line 26, in submit_data > helper = var[r].get() > TypeError: list indices must be integers, not IntVar > I'm willing to give additional info. Thank you in advance. (untested) for r in var: helper = var[r.get()] I think you need to call get on the IntVar instance to get an int that can be used to index the list. -- https://mail.python.org/mailman/listinfo/python-list
Re: gotta love radio buttons
On 01/05/2014 10:18 AM, eneskri...@gmail.com wrote: So, I'm having this radio button issue in tkinter: First I assign the IntVar: var = [] while i < self.something: var.append(IntVar()) i += 2 Later on I use them, but I get this error: for r in var: helper = var[r].get() self.something_else[helper] += 1 Then, this happens: Traceback (most recent call last): File "F:\Portable Python 3.2.5.1\App\lib\tkinter\__init__.py", line 1456, in __call__ return self.func(*args) File "(Not giving this)", line 26, in submit_data helper = var[r].get() TypeError: list indices must be integers, not IntVar I'm willing to give additional info. Thank you in advance. These two lines for r in var: helper = var[r].get() are being redundant. The loop returns elements from the list (one-by-one). Also var[r] attempts to return an element from the list (indexed by r -- expected to be an integer). Either of these remove the redundancy (but the first is more Pythonic) for r in var: helper = r.get() or for i in range(len(var)): helper = var[i].get() Gary Herron -- https://mail.python.org/mailman/listinfo/python-list
Re: gotta love radio buttons
Now it is giving me this error, after changing to helper = var[r.get()] line 27, in submit_data self.something_else[r][1] += 1 TypeError: list indices must be integers, not IntVar -- https://mail.python.org/mailman/listinfo/python-list
Re: [ANN] gg_scrapper -- scrapping of the Google Groups
Matěj, Thanks for your efforts! However, you should only have one 'p' in scraping and scraper. ;) -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: converting a string to a function parameter
Il giorno venerdì 13 marzo 2009 08:52:39 UTC+1, koranthala ha scritto: > Hi, > Is it possible to convert a string to a function parameter? > Ex: > str = 'True, type=rect, sizes=[3, 4]' > and I should be able to use it as: > test(convert(str)) and the behaviour should be same as calling test > with those values : > i.e. test(True, type=rect, sizes=[3, 4]) > > I tried eval, but it did not work. And any other mechanism I think > turns out to be creating a full fledged python parser. > > Is there any mechanism with which we can do this straight away? I need the exact opposite, what is the inverse function? example: i pass to a function an argument m=[654,54,65] def function(m): return takethenameof(m) and it have to return to me 'm' not [654,54,65] or '[654,54,65]' anybody can help? i think that when one is talking about a function he have to talk also of the inverse function (also because google have problems searching about this...) -- https://mail.python.org/mailman/listinfo/python-list
Re: gotta love radio buttons
On 01/05/2014 10:47 AM, eneskri...@gmail.com wrote: Now it is giving me this error, after changing to helper = var[r.get()] line 27, in submit_data self.something_else[r][1] += 1 TypeError: list indices must be integers, not IntVar In such an easy case, you really ought to be able to read the error and understand it rather than needing to rely on us to do that for you. The message: List indices must be integers, not IntVar clearly indicates you are indexing a list with something of type IntVar instead of the required int.That would have to be the ...[r]. The value of r is *not* an integer, it's an IntVar which is container of an int but not an int itself. You can access the contained int with r.get(), so perhaps ...[r.get()] is what you want. (Or perhaps not... We really don't know what you are trying to do here.) Reading error messages and understanding tracebacks are skills well worth trying to develop. Good luck. Gary Herron -- https://mail.python.org/mailman/listinfo/python-list
Re: converting a string to a function parameter
On 1/5/14 2:39 PM, pietrod...@gmail.com wrote: Il giorno venerdì 13 marzo 2009 08:52:39 UTC+1, koranthala ha scritto: Hi, Is it possible to convert a string to a function parameter? Ex: str = 'True, type=rect, sizes=[3, 4]' and I should be able to use it as: test(convert(str)) and the behaviour should be same as calling test with those values : i.e. test(True, type=rect, sizes=[3, 4]) I tried eval, but it did not work. And any other mechanism I think turns out to be creating a full fledged python parser. Is there any mechanism with which we can do this straight away? I need the exact opposite, what is the inverse function? example: i pass to a function an argument m=[654,54,65] def function(m): return takethenameof(m) and it have to return to me 'm' not [654,54,65] or '[654,54,65]' anybody can help? i think that when one is talking about a function he have to talk also of the inverse function (also because google have problems searching about this...) The difficulty in writing such a function is that values don't have unique names, if they have names at all. What should be returned in these cases? m = [654, 54, 65] def function(m): m2 = m m3 = m[:] takethenameof(m) takethenameof(m2) takethenameof(m3) takethenameof(m[:]) takethenameof(2) takethenameof(2+2) There are samples online that try to do a "reasonable" job of this, but my googling isn't turning them up... -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: [ANN] gg_scrapper -- scrapping of the Google Groups
On 05/01/2014 19:12, Ethan Furman wrote: Matěj, Thanks for your efforts! However, you should only have one 'p' in scraping and scraper. ;) -- ~Ethan~ My hopes were falsely raised when I first saw the title :) -- 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: converting a string to a function parameter
On 01/05/2014 11:39 AM, pietrod...@gmail.com wrote: Il giorno venerdì 13 marzo 2009 08:52:39 UTC+1, koranthala ha scritto: Hi, Is it possible to convert a string to a function parameter? Ex: str = 'True, type=rect, sizes=[3, 4]' and I should be able to use it as: test(convert(str)) and the behaviour should be same as calling test with those values : i.e. test(True, type=rect, sizes=[3, 4]) I tried eval, but it did not work. And any other mechanism I think turns out to be creating a full fledged python parser. Is there any mechanism with which we can do this straight away? I need the exact opposite, what is the inverse function? example: i pass to a function an argument m=[654,54,65] def function(m): return takethenameof(m) and it have to return to me 'm' not [654,54,65] or '[654,54,65]' anybody can help? i think that when one is talking about a function he have to talk also of the inverse function (also because google have problems searching about this... Absolutely not. Objects (like [654,54,65]) do not have names, never did and never will! Objects do have a type and a value (and an identity), but not a name. Various namespaces will have dictionary-like associations between a name (like "m") and an object, and it *is* possible to get your hands on a (dictionary representing a) namespace and search it, but this is troublesome. For instance, consider this small variation of your code: def function(m): return takethenameof(m) a=[654,54,65] b = a function(a) While function is running, there will be three names associated with the list object. The outer namespace will have "a" and "b" associated with the list object, and the namespace local to function will have "m" associated with the same object. That's one object associated with three names in two different namespaces. Gary Herron -- https://mail.python.org/mailman/listinfo/python-list
Postfix conditionals
Hi,
AFAIK, we do not have "postfix conditionals" in Python, i.e. a condition
appended to a
statement, which determines whether the statement runs or not:
py> for i in [False]:
... break if not i
The above piece of code is equivalent to this in Python:
py> for i in [False]:
...if not i
...break
I believe that the first example is superior to the second example when
the two is compared
for readability and intuitiveness. We already have a ternary statement
that looks similar,
py> print('hi') if True else None
so I reckon there would be no breakage in old code if this kind of
syntax was added. Ruby has
this, and AFAIK Perl also does.
I lack the knowledge of whether the community has opinions on this kind
of notation, so I am
posting this here instead of the ideas list. What are your thoughts on
this?
gk
--
https://mail.python.org/mailman/listinfo/python-list
Re: Postfix conditionals
In article , Göktu⬠Kayaalp wrote: >py> for i in [False]: >... break if not i Python is not Perl. -- https://mail.python.org/mailman/listinfo/python-list
Re: Postfix conditionals
On 05-01-2014 22:41, Roy Smith wrote: In article , Göktu€ Kayaalp wrote: py> for i in [False]: ... break if not i Python is not Perl. Well done! Good for you, that you know the fact; but you are not being constructive. Python is not C either, but we have the while loop. Python is not Smalltalk, but we have classes. Python is not LISP, but we have function literals. Hopefully Guido did not have your approach back when he created Python, or we'd have an assembly language or something instead today. -- https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
On 1/5/2014 8:14 AM, Mark Lawrence wrote: http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ I disagree with the following claims: "Looking at that you can see that Python 3 removed something: support for non Unicode data text. " I believe 2.7 str text methods like .upper only supported ascii. General non-unicode bytes text support would require an encoding as an attribute of the bytes text object. Python never had that. "Python 3 essentially removed the byte-string type which in 2.x was called str." Python 3 renamed unicode as str and str as bytes. Bytes have essentially all the text methods of 2.7 str. Compare dir(str) in 2.7 and dir(bytes) in 3.x. The main change of the class itself is that indexing and iteration yield ints i, 0 <= i < 256. "all text operations now are only defined for Unicode strings." ?? Text methods are still defined on (ascii) bytes. It is true that one text operation -- string formatting no longer is (and there is an issue about that). But one is not all. There is also still discussion about within-class transforms, but they are still possible, even if not with the codecs module. I suspect there are other basic errors, but I mostly quit reading at this point. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Postfix conditionals
On Sun, Jan 5, 2014 at 12:41 PM, Roy Smith wrote: > In article , > Göktu€ Kayaalp wrote: > >>py> for i in [False]: >>... break if not i > > Python is not Perl. Personally, I find the suggested syntax jarring. I'd prefer that it not go into Python. -- https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
On 1/5/2014 8:14 AM, Mark Lawrence wrote: http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ I meant to mention in my previous reply that Armin authored PEP 414, Explicit Unicode Literal for Python 3.3, which brought back the u'' prefix. So it is not the case that core devs pay no attention to Armin when he engages us on an 'improve 3.x' basis. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.0b2
On behalf of the Python development team, I'm pleased to announce the second beta release of Python 3.4. This is a preview release, and its use is not recommended for production settings. Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes. Major new features and changes in the 3.4 release series include: * PEP 428, a "pathlib" module providing object-oriented filesystem paths * PEP 435, a standardized "enum" module * PEP 436, a build enhancement that will help generate introspection information for builtins * PEP 442, improved semantics for object finalization * PEP 443, adding single-dispatch generic functions to the standard library * PEP 445, a new C API for implementing custom memory allocators * PEP 446, changing file descriptors to not be inherited by default in subprocesses * PEP 450, a new "statistics" module * PEP 451, standardizing module metadata for Python's module import system * PEP 453, a bundled installer for the *pip* package manager * PEP 454, a new "tracemalloc" module for tracing Python memory allocations * PEP 456, a new hash algorithm for Python strings and binary data * PEP 3154, a new and improved protocol for pickled objects * PEP 3156, a new "asyncio" module, a new framework for asynchronous I/O Python 3.4 is now in "feature freeze", meaning that no new features will be added. The final release is projected for late February 2014. To download Python 3.4.0b2 visit: http://www.python.org/download/releases/3.4.0/ Please consider trying Python 3.4.0b2 with your code and reporting any new issues you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings, Release Manager larry at hastings.org (on behalf of the entire python-dev team and 3.4's contributors) -- https://mail.python.org/mailman/listinfo/python-list
Re: django question
On 2014-01-05 00:24, Igor Korot wrote: > > While I prefer Django for larger projects, for a lighter-weight > > project such as what you describe, I'd be tempted to go with > > something a little more light-weight unless you need additional > > interactivity. I've recently been impressed with Bottle[2] for a > > small & clean web framework. CherryPy comes somewhere in the > > middle, but I can't say it met my needs/wants on the last project > > where it was chosen (mostly in the documentation department, but > > it's hard to beat Django's stellar docs). > > And thank you for those points as well. > This piece will be for the proof of concept, which later on will go > to much bigger application with reporting, > plotting and different types of data presentation. > Now would it be easy to switch from either on of them to django? > Or is there a better choice for the main application? Integration is one of the things that Django does particularly well: out of the box, you get a web framework, database abstraction (ORM), templating, out-of-the-box functionality, and PHENOMENAL documentation. The others just bring the web-framework to the table and *you* then have to choose your templating engine (and ORM if you're using one). Some people see this as an advantage, some see it as a disadvantage. If you like a particular templating engine (Mako, Jinja, etc) or ORM (SQLAlchemy, SQLObject, etc), you /can/ use them in Django or other frameworks, but in Django, you'd be fighting the Django Way™ and don't get to take advantage of some of the tight integration in areas where it does some of the hard work for you (such as integration into the admin interface). I haven't found it to be that easy to directly transition projects between Django and other frameworks. Jumping from Bottle to CherryPy might be easier, as the non-framework parts (templating, ORM) would/should mostly stay the same. Depending on the scope of your work, it might be possible to just use something light-weight like Bottle to get a demo up and running, then scrap it and start mostly-from-scratch on a Django project once you've impressed folks with a proof-of-concept. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: django question
In article , Tim Chase wrote: > Integration is one of the things that Django does particularly well: > out of the box, you get a web framework, database abstraction (ORM), > templating, out-of-the-box functionality, and PHENOMENAL > documentation. The others just bring the web-framework to the table > and *you* then have to choose your templating engine (and ORM if > you're using one). Some people see this as an advantage, some see it > as a disadvantage. If you like a particular templating engine (Mako, > Jinja, etc) or ORM (SQLAlchemy, SQLObject, etc), you /can/ use them in > Django or other frameworks, but in Django, you'd be fighting the > Django Way⢠and don't get to take advantage of some of the tight > integration in areas where it does some of the hard work for you > (such as integration into the admin interface). On the other hand, it's all modular enough that it's quite reasonable to plug in your own components. For example, at Songza, we don't use the django ORM at all (we use mongoengine). We also have a number of django-based services which don't use templates at all (we return JSON objects). Neither of these required any major surgery to do this. In fact, for a lot of what we do, all we really get from django is the request parsing, URL routing, middleware scaffolding, and cache interface. But, that's enough to be worthwhile. > I haven't found it to be that easy to directly transition projects > between Django and other frameworks. One of the things we try to do is put as little in the views as possible. Views should be all about accepting and validating request parameters, and generating output (be that HTML via templates, or JSON, or whatever). All the business logic should be kept isolated from the views. The better (and more disciplined) you are about doing this, the easier it will be to move your business logic to a different framework. That's not to say it will be *easy*, but you can certainly make things harder on yourself than they need to be if you don't keep things distinct. Oh, and yes, the django team does a really amazing job on the docs. -- https://mail.python.org/mailman/listinfo/python-list
Re: Dos cursor and input management.
Dennis, Loose terminology. The Command terminal within windows which the app will be executed in. Not native DOS. On 06/01/2014, at 3:48 AM, Denis McMahon wrote: > On Sun, 05 Jan 2014 20:25:11 +1100, Sean Murphy wrote: > >> The module must work under dos for now. Eventually Mac. > > Do you mean a windows command line terminal window, or some *nix shell? > > As far as I know, dos as an operating system hasn't been around since > version 6.22 or thereabouts, although I believe ms windows provides a dos > shell like interface on top of the windows os. I'm not aware that any > version of python is supported on dos, but I may be wrong, there may be > some 15 year old hardware running dos somewhere that also has a working > python install. > > I associate dos with machines of the pre-pentium era, although I suspect > that might not be quite accurate either. > > -- > Denis McMahon, denismfmcma...@gmail.com > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Postfix conditionals
On Sun, Jan 5, 2014 at 12:24 PM, Göktuğ Kayaalp wrote:
> Hi,
>
> AFAIK, we do not have "postfix conditionals" in Python, i.e. a condition
> appended to a
> statement, which determines whether the statement runs or not:
>
> py> for i in [False]:
> ... break if not i
>
> The above piece of code is equivalent to this in Python:
>
> py> for i in [False]:
> ...if not i
> ...break
>
> I believe that the first example is superior to the second example when the
> two is compared
> for readability and intuitiveness.
I'm going to have to disagree. I dislike how this obscures the
if-statement, complicates the language grammar, and adds another
unnecessary way to express the same thing (which violates TOOWTDI)
with little countervailing benefit.
> We already have a ternary statement that
> looks similar,
>
> py> print('hi') if True else None
Actually, to be pedantic, it's a ternary *expression*. Using it purely
for side-effects (i.e. as a statement) is rather unidiomatic, in the
same way that abusing list comprehensions, e.g.:
[print(i) for i in range(42)]
is frowned upon.
Not to mention that the ternary doesn't work for actual statements
(print() is just a function call in Python 3):
>>> (x = 1) if True else (x = 2)
File "", line 1
(x = 1) if True else (x = 2)
^
SyntaxError: invalid syntax
> so I reckon there would be no breakage in old code if this kind of syntax
> was added. Ruby has
> this, and AFAIK Perl also does.
>
> I lack the knowledge of whether the community has opinions on this kind of
> notation, so I am
> posting this here instead of the ideas list. What are your thoughts on
> this?
You can already write:
for i in [False]:
if not i: break
if you feel the need for terseness or a one-liner. Perhaps this
satisfies your desire?
Cheers,
Chris
--
https://mail.python.org/mailman/listinfo/python-list
Fwd: Re: Postfix conditionals
This was sent to me as a private reply to a question that I have posted
to python-list@python.org, so I am forwarding it to here.
Chris, please send your messages to the list, and cc the OP.
Original Message
Subject:Re: Postfix conditionals
Date: Sun, 5 Jan 2014 14:09:14 -0800
From: Chris Rebert
To: Göktuğ Kayaalp
CC: Python
On Sun, Jan 5, 2014 at 12:24 PM, Göktuğ Kayaalp wrote:
Hi,
AFAIK, we do not have "postfix conditionals" in Python, i.e. a condition
appended to a
statement, which determines whether the statement runs or not:
py> for i in [False]:
... break if not i
The above piece of code is equivalent to this in Python:
py> for i in [False]:
...if not i
...break
I believe that the first example is superior to the second example when the
two is compared
for readability and intuitiveness.
I'm going to have to disagree. I dislike how this obscures the
if-statement, complicates the language grammar, and adds another
unnecessary way to express the same thing (which violates TOOWTDI)
with little countervailing benefit.
We already have a ternary statement that
looks similar,
py> print('hi') if True else None
Actually, to be pedantic, it's a ternary *expression*. Using it purely
for side-effects (i.e. as a statement) is rather unidiomatic, in the
same way that abusing list comprehensions, e.g.:
[print(i) for i in range(42)]
is frowned upon.
Not to mention that the ternary doesn't work for actual statements
(print() is just a function call in Python 3):
>>> (x = 1) if True else (x = 2)
File "", line 1
(x = 1) if True else (x = 2)
^
SyntaxError: invalid syntax
so I reckon there would be no breakage in old code if this kind of syntax
was added. Ruby has
this, and AFAIK Perl also does.
I lack the knowledge of whether the community has opinions on this kind of
notation, so I am
posting this here instead of the ideas list. What are your thoughts on
this?
You can already write:
for i in [False]:
if not i: break
if you feel the need for terseness or a one-liner. Perhaps this
satisfies your desire?
Cheers,
Chris
--
https://mail.python.org/mailman/listinfo/python-list
Re: Blog "about python 3"
On 1/5/2014 9:23 AM, wxjmfa...@gmail.com wrote: Le samedi 4 janvier 2014 23:46:49 UTC+1, Terry Reedy a écrit : On 1/4/2014 2:10 PM, wxjmfa...@gmail.com wrote: And I could add, I *never* saw once one soul, who is explaining what I'm doing wrong in the gazillion of examples I gave on this list. If this is true, it is because you have ignored and not read my numerous, relatively polite posts. To repeat very briefly: 1. Cherry picking (presenting the most extreme case as representative). 2. Calling space saving a problem (repeatedly). >> 3. Ignoring bug fixes. ... My examples are ONLY ILLUSTRATING, this FSR is wrong by design, can be on the side of memory, performance, linguistic or even typography. Let me expand on 3 of my points. First, performance == time: Point 3. You correctly identified a time regression in finding a character in a string. I saw that the slowdown was *not* inherent in the FSR but had to be a glitch in the code, and reported it on pydev with the hope that someone would fix it even if it were not too important in real use cases. Someone did. Point 1. You incorrectly generalized that extreme case. I reported (a year ago last September) that the overall stringbench results were about the same. I also pointed out that there is an equally non-representative extreme case in the opposite direction, and that it would equally be wrong of me to use that to claim that FSR is faster. (It turns out that this FSR speed advantage *is* inherent in the design.) Memory: Point 2. A *design goal* of FSR was to save memory relative to UTF-32, which is what you apparently prefer. Your examples show that FSF successfully met its design goal. But you call that success, saving memory, 'wrong'. On what basis? You *claim* the FSR is 'wrong by design', but your examples only show that is was temporarily wrong in implementation as far as speed and correct by design as far as memory goes. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Re: Postfix conditionals
On Sun, Jan 5, 2014 at 2:12 PM, Göktuğ Kayaalp wrote: > > This was sent to me as a private reply No, it was sent as a public reply via Reply-All; note that python-list was CC-ed, which works just fine: https://mail.python.org/pipermail/python-list/2014-January/663858.html > to a question that I have posted > to python-list@python.org, so I am forwarding it to here. > Original Message > Subject: Re: Postfix conditionals > Date: Sun, 5 Jan 2014 14:09:14 -0800 > From: Chris Rebert > To: Göktuğ Kayaalp > CC: Python -- https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
05.01.14 15:34, Chris Angelico написав(ла): Why is a StopIteration bubbling up? (I don't have Flask, so I can't verify this.) Is it as simple as "this should be raising from None", or is there something else going on? Yes, it is. Stdlib json module uses "from None". -- https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
I wonder why nobody complains about the absent of implicit conversion between int and str. In PHP you can write 2 + "3" and got 5, but in Python this is an error. So sad! -- https://mail.python.org/mailman/listinfo/python-list
Re: Blog "about python 3"
On 1/5/2014 9:23 AM, wxjmfa...@gmail.com wrote: My examples are ONLY ILLUSTRATING, this FSR is wrong by design, Let me answer you a different way. If FSR is 'wrong by design', so are the alternatives. Hence, the claim is, in itself, useless as a guide to choosing. The choices: * Keep the previous complicated system of buggy narrow builds on some systems and space-wasting wide builds on other systems, with Python code potentially acting differently on the different builds. I am sure that you agree that this is a bad design. * Improved the dual-build system by de-bugging narrow builds. I proposed to do this (and gave Python code proving the idea) by adding the complication of an auxiliary array of indexes of astral chars in a UTF-16 string. I suspect you would call this design 'wrong' also. * Use the memory-wasting UTF-32 (wide) build on all systems. I know you do not consider this 'wrong', but come on. From an information theoretic and coding viewpoint, it clearly is. The top (4th) byte is *never* used. The 3rd byte is *almost never* used. The 2nd byte usage ranges from common to almost never for different users. Memory waste is also time waste, as moving information-free 0 bytes takes the same time as moving informative bytes. Here is the beginning of the rationale for the FSR (from http://www.python.org/dev/peps/pep-0393/ -- have you ever read it?). "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...". The memory waste was a reason to stick with 2.7. It could break code that worked in 2.x. By removing the waste, the FSR makes switching to Python 3 more feasible for some people. It was a response to real problems encountered by real people using Python. It fixed both classes of complaint about the previous system. * Switch to the time-wasting UTF-8 for text storage, as some have done. This is different from using UTF-8 for text transmission, which I hope becomes the norm soon. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Blog "about python 3"
On 1/5/2014 11:51 AM, Chris Angelico wrote:
On Mon, Jan 6, 2014 at 3:34 AM, Roy Smith wrote:
Amazon's (short-term) goal is to increase their market share by
undercutting everybody on price. They have implemented a box-packing
algorithm which clearly has a bug in it. You are complaining that they
failed to deliver your purchase in good condition, and apparently don't
care. You're right, they don't. The cost to them to manually correct
this situation exceeds the value. This is one shipment. It doesn't
matter.
If it stopped there, it would be mildly annoying ("1% of our shipments
will need to be replaced, that's a 1% cost for free replacements").
The trouble is that they don't care about the replacement either, so
it's really that 100% (or some fairly large proportion) of their
shipments will arrive with some measure of damage, and they're hoping
that their customers' threshold for complaining is often higher than
the damage sustained. Which it probably is, a lot of the time.
My wife has gotten several books from Amazon and partners and we have
never gotten one loose enough in a big enough box to be damaged. Either
the box is tight or has bubble packing. Leaving aside partners, maybe
distribution centers have different rules.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
Chris Angelico wrote:
> But this bit looks odd:
>
> """
> For instance passing a urllib request object to Flask's JSON parse
> function breaks on Python 3 but works on Python 2 as a result of this:
>
from urllib.request import urlopen
r = urlopen('https://pypi.python.org/pypi/Flask/json')
from flask import json
json.load(r)
> Traceback (most recent call last):
> File "decoder.py", line 368, in raw_decode
> StopIteration
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
> File "", line 1, in
> ValueError: No JSON object could be decoded
> """
I'm not sure about the "works on Python 2" part. Is Armin just complaining
about the StopIteration being visible in Python 3 but hidden in Python 2? I
don't have Flask installed, and aren't going to install it just for this.
> Why is a StopIteration bubbling up? (I don't have Flask, so I can't
> verify this.) Is it as simple as "this should be raising from None",
> or is there something else going on?
Remember that "raise Spam from None" only works from Python 3.3 onwards.
Personally, I think that releasing nested tracebacks before having a way to
suppress the display was a strategic blunder, but it's fixed now, at least
for those who can jump straight to 3.3 and not bother supporting 3.1 and
3.2.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
[OT] Migrating from non-free programs to LibreOffice (was: "More About Unicode in Python 2 and 3")
Chris Angelico writes: > Maybe it's the better way, but like trying to get people to switch > from MS Word onto an open system, it's far easier to push for Open > Office than for LaTeX. If you're going to be pushing people to a free software system, OpenOffice is no longer the one to choose; its owners several years ago shunted it to a dead end where very little active development can happen, and its development community have moved to more productive ground. Rather, the same code base has since 2010 been actively developed as LibreOffice http://libreoffice.org/>, and it is now showing far more improvement and document compatibility as a result. In short: Everything that was good about OpenOffice is now called LibreOffice, which had to change its name only because the owners of that name refused to let it go. > Getting your head around a whole new way of thinking about your data > is work, and people want to be lazy. (That's not a bad thing, by the > way. Laziness means schedules get met.) Right. I think shifting people to LibreOffice is an excellent and realistic step toward imcreasing people's software and data freedom. -- \ “It is far better to grasp the universe as it really is than to | `\persist in delusion, however satisfying and reassuring.” —Carl | _o__)Sagan | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
On 01/05/2014 02:32 PM, Serhiy Storchaka wrote: I wonder why nobody complains about the absent of implicit conversion between int and str. In PHP you can write 2 + "3" and got 5, but in Python this is an error. So sad! I'd want my implicit conversion of 2 + '3' to get '23' That's why it's not there... Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: [ANN] gg_scrapper -- scrapping of the Google Groups
Matej Cepl writes: > Did you try to archive email list hosted on the Google Groups? Were > you endlessly frustrated by the black hole which is Google Groups, > conscpicious by its absence on the Data Liberation Front website? Yes, > I was too_ Yes, I am very frustrated by everything Google Groups does. It is in sore need of scrapping. > So, I have created a script webscrapping a google group and created > gg_scrapper_ . Hooray! Thank you for any progress toward scrapping Google Groups https://en.wiktionary.org/wiki/scrapping>. I look forward with great hope to Google Groups being scrapped! -- \ “And if I laugh at any mortal thing, / 'Tis that I may not | `\ weep.” —“Lord” George Gordon Noel Byron, _Don Juan_ | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
On 01/05/2014 03:31 PM, Emile van Sebille wrote: On 01/05/2014 02:32 PM, Serhiy Storchaka wrote: I wonder why nobody complains about the absent of implicit conversion between int and str. In PHP you can write 2 + "3" and got 5, but in Python this is an error. So sad! I'd want my implicit conversion of 2 + '3' to get '23' Huh. And here I thought 'twenty-three' was the right answer! ;) -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Blog "about python 3"
On Mon, Jan 6, 2014 at 9:56 AM, Terry Reedy wrote:
> On 1/5/2014 11:51 AM, Chris Angelico wrote:
>>
>> On Mon, Jan 6, 2014 at 3:34 AM, Roy Smith wrote:
>>>
>>> Amazon's (short-term) goal is to increase their market share by
>>> undercutting everybody on price. They have implemented a box-packing
>>> algorithm which clearly has a bug in it. You are complaining that they
>>> failed to deliver your purchase in good condition, and apparently don't
>>> care. You're right, they don't. The cost to them to manually correct
>>> this situation exceeds the value. This is one shipment. It doesn't
>>> matter.
>>
>>
>> If it stopped there, it would be mildly annoying ("1% of our shipments
>> will need to be replaced, that's a 1% cost for free replacements").
>> The trouble is that they don't care about the replacement either, so
>> it's really that 100% (or some fairly large proportion) of their
>> shipments will arrive with some measure of damage, and they're hoping
>> that their customers' threshold for complaining is often higher than
>> the damage sustained. Which it probably is, a lot of the time.
>
>
> My wife has gotten several books from Amazon and partners and we have never
> gotten one loose enough in a big enough box to be damaged. Either the box is
> tight or has bubble packing. Leaving aside partners, maybe distribution
> centers have different rules.
Or possibly (my personal theory) the CS rep I was talking to just
couldn't be bothered solving the problem. Way way too much work to
make the customer happy, much easier and cheaper to give a 30% refund
and hope that shuts him up.
But they managed to ship two books (the original and the replacement)
with insufficient packaging. Firstly, that requires the square of the
probability of failure; and secondly, if you care even a little bit
about making your customers happy, put a little note on the second
order instructing people to be particularly careful of this one! Get
someone to check it before it's sent out. Make sure it's right this
time. I know that's what we used to do in the family business whenever
anything got mucked up.
(BTW, I had separately confirmed that the problem was with Amazon, and
not - as has happened to me with other shipments - caused by
Australian customs officials opening the box, looking through it, and
then packing it back in without its protection. No, it was shipped
that way.)
Anyway, this is veering so far off topic that we're at no risk of
meeting any Python Alliance ships - as Mal said, we're at the corner
of No and Where. But maybe someone can find an on-topic analogy to put
some tentative link back into this thread...
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
On Mon, Jan 6, 2014 at 9:56 AM, Steven D'Aprano
wrote:
>> Why is a StopIteration bubbling up? (I don't have Flask, so I can't
>> verify this.) Is it as simple as "this should be raising from None",
>> or is there something else going on?
>
> Remember that "raise Spam from None" only works from Python 3.3 onwards.
> Personally, I think that releasing nested tracebacks before having a way to
> suppress the display was a strategic blunder, but it's fixed now, at least
> for those who can jump straight to 3.3 and not bother supporting 3.1 and
> 3.2.
Fair enough. If it's a problem, I'm sure Flask could do something like
(untested):
error = False
try:
next(whatever)
except StopIteration:
error = True
if error: raise ValueError("...")
which would work across all. But that's assuming that it really is
just a small matter of traceback ugliness. The post implies that it's
a lot worse than that.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: django question
Hi, ALL, Well, my employer does not know anything about web programming and I don't know anything about web programming and this is my first job with python. So since django is a well documented framework I guess it will be easier to go with a well documented framework. Thank you everybody for such a good input. Happy New Year and happy coding in this year as well. ;-) On Sun, Jan 5, 2014 at 1:50 PM, Roy Smith wrote: > In article , > Tim Chase wrote: > >> Integration is one of the things that Django does particularly well: >> out of the box, you get a web framework, database abstraction (ORM), >> templating, out-of-the-box functionality, and PHENOMENAL >> documentation. The others just bring the web-framework to the table >> and *you* then have to choose your templating engine (and ORM if >> you're using one). Some people see this as an advantage, some see it >> as a disadvantage. If you like a particular templating engine (Mako, >> Jinja, etc) or ORM (SQLAlchemy, SQLObject, etc), you /can/ use them in >> Django or other frameworks, but in Django, you'd be fighting the >> Django Way™ and don't get to take advantage of some of the tight >> integration in areas where it does some of the hard work for you >> (such as integration into the admin interface). > > On the other hand, it's all modular enough that it's quite reasonable to > plug in your own components. > > For example, at Songza, we don't use the django ORM at all (we use > mongoengine). We also have a number of django-based services which > don't use templates at all (we return JSON objects). Neither of these > required any major surgery to do this. > > In fact, for a lot of what we do, all we really get from django is the > request parsing, URL routing, middleware scaffolding, and cache > interface. But, that's enough to be worthwhile. > >> I haven't found it to be that easy to directly transition projects >> between Django and other frameworks. > > One of the things we try to do is put as little in the views as > possible. Views should be all about accepting and validating request > parameters, and generating output (be that HTML via templates, or JSON, > or whatever). All the business logic should be kept isolated from the > views. The better (and more disciplined) you are about doing this, the > easier it will be to move your business logic to a different framework. > > That's not to say it will be *easy*, but you can certainly make things > harder on yourself than they need to be if you don't keep things > distinct. > > Oh, and yes, the django team does a really amazing job on the docs. > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
On Mon, Jan 6, 2014 at 10:45 AM, Ethan Furman wrote: > On 01/05/2014 03:31 PM, Emile van Sebille wrote: >> >> On 01/05/2014 02:32 PM, Serhiy Storchaka wrote: >>> >>> I wonder why nobody complains about the absent of implicit conversion >>> between int and str. In PHP you can write 2 + "3" and got 5, but in >>> Python this is an error. So sad! >> >> I'd want my implicit conversion of 2 + '3' to get '23' > > Huh. And here I thought 'twenty-three' was the right answer! ;) I quite like 2+"3" being "23", as it simplifies a lot of string manipulation. But there's another option: 2+"3456" could be "56". That one makes even more sense... doesn't it? I mean, C does it so it must make sense... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Migrating from non-free programs to LibreOffice (was: "More About Unicode in Python 2 and 3")
On Mon, Jan 6, 2014 at 10:30 AM, Ben Finney wrote: > Chris Angelico writes: > >> Maybe it's the better way, but like trying to get people to switch >> from MS Word onto an open system, it's far easier to push for Open >> Office than for LaTeX. > > If you're going to be pushing people to a free software system, > OpenOffice is no longer the one to choose; its owners several years ago > shunted it to a dead end where very little active development can > happen, and its development community have moved to more productive > ground. Handwave, handwave. The FOSS office suite that comes conveniently in the Debian repositories. It was OO a while ago, it's now LO, but same difference. If LO ever renames and becomes FreeOffice or ZOffice or anything else under the sun, it would still be the easier option for MS Word users to switch to. (And actually, I haven't been pushing people off MS Word so much as off DeScribe Word Processor. But since most people here won't have heard of that, I went for the more accessible analogy.) >> Getting your head around a whole new way of thinking about your data >> is work, and people want to be lazy. (That's not a bad thing, by the >> way. Laziness means schedules get met.) > > Right. I think shifting people to LibreOffice is an excellent and > realistic step toward imcreasing people's software and data freedom. Yeah. Which is why I do it. But the other night, my mum was trying to lay out her book in LO, and was having some problems with the system of having each chapter in a separate file. (Among other things, styles weren't shared across them all, so a tweak to a style means opening up every chapter and either doing a parallel edit or figuring out how to import styles.) So yes, it's a realistic and worthwhile step, but it's not a magic solution to all problems. She doesn't have time to learn a whole new system. Maybe - in the long term - LaTeX would actually save her time, but it's certainly a much harder 'sell' than LO. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
On 01/05/2014 02:56 PM, Steven D'Aprano wrote: Remember that "raise Spam from None" only works from Python 3.3 onwards. Personally, I think that releasing nested tracebacks before having a way to suppress the display was a strategic blunder [...] I would just call it really really annoying. ;) On the upside adding 'from None' was a small enough project that I was able to get it going, and that was the bridge to eventually becoming a dev. :D -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
On Sun, Jan 5, 2014 at 2:32 PM, Serhiy Storchaka wrote: > I wonder why nobody complains about the absent of implicit conversion > between int and str. In PHP you can write 2 + "3" and got 5, but in Python > this is an error. So sad! I like Python strongly typed, thank you very much. Please don't break it. Not raising an exception when implicitly converting types tends to lead to hard-to-track-down bugs. -- https://mail.python.org/mailman/listinfo/python-list
Re: Blog "about python 3"
Chris Angelico wrote about Amazon: > And yet I can't disagree with your final conclusion. Empirical > evidence goes against my incredulous declaration that "surely this is > a bad idea" - according to XKCD 1165, they're kicking out nearly a > cubic meter a SECOND of packages. Yes, but judging by what you described as their packing algorithm that's probably only a tenth of a cubic metre of *books*, the rest being empty box for the book to rattle around in and get damaged. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
On 1/5/14 8:22 AM, Ned Batchelder wrote: On 1/5/14 8:14 AM, Mark Lawrence wrote: http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ Please don't shoot the messenger :) With all of the talk about py 2 vs. py3 these days, this is the blog post that I think deserves the most real attention. I haven't had to do the kind of coding that Armin is talking about, but I've heard more than one person talk about the difficulty of it in Python 3. If anyone wants Python 3 uptake improved, the best thing would be to either explain to Armin how he missed the easy way to do what he wants (seems unlikely), or advocate to the core devs why they should change things to improve this situation. OK, let's see what we got from three core developers on this list: - Antoine dismissed the post as "a rant". - Terry took issue with three claims made, and ended with, "I suspect there are other basic errors, but I mostly quit reading at this point." - Serhiy made a sarcastic comment comparing Python 3's bytes/unicode handling with Python 2's int/str handling, implying that since int/str wasn't a problem, then bytes/unicode isn't either. This is discouraging. Armin is a prolific and well-known contributor to a number of very popular packages. He's devoted a great deal of time to the Python ecosystem, including writing the PEP that got u"" literals back in Python 3.3. If he's having trouble with Python 3, it's a serious problem. You can look through his problems and decide that he's "wrong," or that he's "ranting," but that doesn't change the fact that Python 3 is encountering friction. What happens when a significant fraction of your customers are "wrong"? Core developers: I thank you for the countless hours you have devoted to building all of the versions of Python. I'm sure in many ways it's a thankless task. But you have a problem. What's the point in being right if you end up with a product that people don't use? If Armin, with all of his skills and energy, is having problems using your product, then there's a problem. Compounding that problem is the attitude that dismisses him as wrong. Kenneth Reitz's reaction to Armin's blog post was: "A fantastic article about why Python 2 is a superior programming language for my personal use case." https://twitter.com/kennethreitz/status/419889312935993344 So now we have two revered developers vocally having trouble with Python 3. You can dismiss their concerns as niche because it's only network programming, but that would be a mistake. Given the centrality of network programming in today's world, and the dominance these two developers have in building libraries to solve networking problems, I think someone should take their concerns seriously. Maybe there are core developers who are trying hard to solve the problems Kenneth and Armin are facing. It would be great if that work was more visible. I don't see it, and apparently Armin doesn't either. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Blog "about python 3"
Roy Smith wrote: > In article , > Chris Angelico wrote: > >> On Sun, Jan 5, 2014 at 2:20 PM, Roy Smith wrote: >> > I've got a new sorting algorithm which is guaranteed to cut 10 seconds >> > off the sorting time (i.e. $0.10 per package). The problem is, it >> > makes a mistake 1% of the time. >> >> That's a valid line of argument in big business, these days, because >> we've been conditioned to accept low quality. But there are places >> where quality trumps all, and we're happy to pay for that. Allow me to >> expound two examples. >> >> 1) Amazon >> >> http://www.amazon.com/exec/obidos/ASIN/1782010165/evertype-20 >> >> I bought this book a while ago. It's about the size of a typical >> paperback. It arrived in a box too large for it on every dimension, >> with absolutely no packaging. I complained. Clearly their algorithm >> was: "Most stuff will get there in good enough shape, so people can't >> be bothered complaining. And when they do complain, it's cheaper to >> ship them another for free than to debate with them on chat." > > You're missing my point. > > Amazon's (short-term) goal is to increase their market share by > undercutting everybody on price. They have implemented a box-packing > algorithm which clearly has a bug in it. You are complaining that they > failed to deliver your purchase in good condition, and apparently don't > care. You're right, they don't. The cost to them to manually correct > this situation exceeds the value. This is one shipment. It doesn't > matter. You are one customer, you don't matter either. Seriously. > This may be annoying to you, but it's good business for Amazon. For > them, fast and cheap is absolutely better than correct. One, you're missing my point that to Amazon, "fast and cheap" *is* correct. They would not agree with you that their box-packing algorithm is buggy, so long as their customers don't punish them for it. It meets their requirements: ship parcels as quickly as possible, and push as many of the costs (damaged books) onto the customer as they can get away with. If they thought it was buggy, they would be trying to fix it. Two, nobody is arguing against the concept that different parties have different concepts of what's correct. To JMF, the flexible string representation is buggy, because he's detected a trivially small slowdown in some artificial benchmarks. To everyone else, it is not buggy, because it does what it sets out to do: save memory while still complying with the Unicode standard. A small slowdown on certain operations is a cost worth paying. Normally, the definition of "correct" that matters is that belonging to the paying customer, or failing that, the programmer who is giving his labour away for free. (Extend this out to more stakeholders if you wish, but the more stakeholders you include, the harder it is to get consensus on what's correct and what isn't.) From the perspective of Amazon's customers, presumably so long as the cost of damaged and lost books isn't too high, they too are willing to accept Amazon's definition of "correct" in order to get cheap books, or else they would buy from someone else. (However, to the extent that Amazon has gained monopoly power over the book market, that reasoning may not apply. Amazon is not *technically* a monopoly, but they are clearly well on the way to becoming one, at which point the customer has no effective choice and the market is no longer free.) The Amazon example is an interesting example of market failure, in the sense that the free market provides a *suboptimal solution* to a problem. We'd all like reasonably-priced books AND reliable delivery, but maybe we can't have both. Personally, I'm not so sure about that. Maybe Jeff Bezos could make do with only five solid gold Mercedes instead of ten[1], for the sake of improved delivery? But apparently not. But I digress... ultimately, you are trying to argue that there is a single absolute source of truth for what counts as "correct". I don't believe there is. We can agree that some things are clearly not correct -- Amazon takes your money and sets the book on fire, or hires an armed military escort costing $20 million a day to deliver your book of funny cat pictures. We might even agree on what we'd all like in a perfect world: cheap books, reliable delivery, and a pony. But in practice we have to choose some features over others, and compromise on requirements, and ultimately we have to make a *pragmatic* choice on what counts as correct based on the functional requirements, not on a wishlist of things we'd like with infinite time and money. Sticking to the Amazon example, what percentage of books damaged in delivery ceases to be a bug in the packing algorithm and becomes "just one of those things"? One in ten? One in ten thousand? One in a hundred billion billion? I do not accept that "book gets damaged in transit" counts as a bug. "More than x% of books get damaged", that's a bug. "Average cost to ship a boo
Re: "More About Unicode in Python 2 and 3"
On 01/05/2014 05:14 AM, Mark Lawrence wrote: Please don't shoot the messenger :) While I don't agree with his assessment of Python 3 in total, I definitely feel his pain with regards to bytestrings in Py3 -- because they don't exist. 'bytes' /looks/ like a bytestring, but really it's just a bunch of integers: --> b'abc 'b'abc' --> b'abc'[1] 98 Maybe for 3.5 somebody *cough* will make a bytestring type for those of us who have to support the lower-level protocols... -- ~Ethan~ *Cast your vote over on Python Ideas! -- https://mail.python.org/mailman/listinfo/python-list
Re: Postfix conditionals
On Sun, 05 Jan 2014 20:24:53 -, Göktuğ Kayaalp wrote: AFAIK, we do not have "postfix conditionals" in Python, i.e. a condition appended to a statement, which determines whether the statement runs or not: py> for i in [False]: ... break if not i The above piece of code is equivalent to this in Python: py> for i in [False]: ...if not i ...break I believe that the first example is superior to the second example when the two is compared for readability and intuitiveness. In my past life as a newcomer to Perl, I thought this too. Postfix conditionals read more like English, so they would be easier to take in and understand. As I wrote more code, I discovered that this didn't seem to be the case; except in very simple cases, I had to mentally transpose the conditional back to the start of the statement to properly comprehend what was going on and what the results would be for my sample data. It looks like a good idea, but I don't think it works that well in practice. -- Rhodri James *-* Wildebeest Herder to the Masses -- https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
On Mon, Jan 6, 2014 at 12:16 PM, Ned Batchelder wrote: > So now we have two revered developers vocally having trouble with Python 3. > You can dismiss their concerns as niche because it's only network > programming, but that would be a mistake. IMO, network programming (at least on the internet) is even more Py3's domain (pun not intended). 1) The internet is global. You WILL come across other languages, other scripts, everything. 2) In most cases, everything is clearly either text or binary, and usually text has an associated (and very clear) encoding (eg HTTP headers). If it's not explicitly given, the RFCs will often stipulate what the encoding should be. It's pretty easy, you don't have to go "Is this Latin-1? Maybe CP-1252? Could it be something else?". 3) The likelihood is high that you'll be working with someone else's code at the other end. Ties in with #2 - this is why the specs are so carefully written. Getting these things right is incredibly important. If I'm writing something that might have to work with anything from anywhere, I want a system that catches potential errors earlier rather than later. I don't want to write interpolated SQL that works perfectly until Mr O'Hara tries to sign up (or, worse, young Robert whose sister is named "Help I'm trapped in a driver's license factory"); I want to get it right from the start. Yes, that means more work to get "Hello, World" going. Yes, it means that I need to get my head around stuff that I didn't think I'd have to. (One time I implemented Oauth manually rather than using a library - the immediate reason was some kind of issue with the library, but I was glad I did, because it meant I actually understood what was going on; came in handy about two weeks later when the far end had a protocol problem.) Most of the complaints about Py3 are "it's harder to get something started (or port from Py2)". My answer is that it's easier to get something finished. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Blog "about python 3"
On Mon, Jan 6, 2014 at 12:23 PM, Steven D'Aprano
wrote:
> (However, to the extent that Amazon has gained monopoly power over the book
> market, that reasoning may not apply. Amazon is not *technically* a
> monopoly, but they are clearly well on the way to becoming one, at which
> point the customer has no effective choice and the market is no longer
> free.)
They don't need a monopoly on the whole book market, just on specific
books - which they did have, in the cited case. I actually asked the
author (translator, really - it's a translation of "Alice in
Wonderland") how he would prefer me to buy, as there are some who sell
on Amazon and somewhere else. There was no alternative to Amazon, ergo
no choice and the market was not free. Like so many things, one choice
("I want to buy Ailice's Anters in Ferlielann") mandates another
("Must buy through Amazon").
I don't know what it cost Amazon to ship me two copies of a book, but
still probably less than they got out of me, so they're still ahead.
Even if they lost money on this particular deal, they're still way
ahead because of all the people who decide it's not worth their time
to spend an hour or so trying to get a replacement. So yep, this
policy is serving Amazon fairly well.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
In article , Chris Angelico wrote: > One time I implemented Oauth manually rather than using a library Me too. You have my sympathy. What a mess. -- https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
On 1/5/14 8:48 PM, Chris Angelico wrote: On Mon, Jan 6, 2014 at 12:16 PM, Ned Batchelder wrote: So now we have two revered developers vocally having trouble with Python 3. You can dismiss their concerns as niche because it's only network programming, but that would be a mistake. IMO, network programming (at least on the internet) is even more Py3's domain (pun not intended). 1) The internet is global. You WILL come across other languages, other scripts, everything. 2) In most cases, everything is clearly either text or binary, and usually text has an associated (and very clear) encoding (eg HTTP headers). If it's not explicitly given, the RFCs will often stipulate what the encoding should be. It's pretty easy, you don't have to go "Is this Latin-1? Maybe CP-1252? Could it be something else?". 3) The likelihood is high that you'll be working with someone else's code at the other end. Ties in with #2 - this is why the specs are so carefully written. Getting these things right is incredibly important. If I'm writing something that might have to work with anything from anywhere, I want a system that catches potential errors earlier rather than later. I don't want to write interpolated SQL that works perfectly until Mr O'Hara tries to sign up (or, worse, young Robert whose sister is named "Help I'm trapped in a driver's license factory"); I want to get it right from the start. Yes, that means more work to get "Hello, World" going. Yes, it means that I need to get my head around stuff that I didn't think I'd have to. (One time I implemented Oauth manually rather than using a library - the immediate reason was some kind of issue with the library, but I was glad I did, because it meant I actually understood what was going on; came in handy about two weeks later when the far end had a protocol problem.) Most of the complaints about Py3 are "it's harder to get something started (or port from Py2)". My answer is that it's easier to get something finished. I like all of this logic, it makes sense to me. But Armin and Kenneth have more experience than I do actually writing networking software. They are both very smart and very willing to do a ton of work. And both are unhappy. I don't know how to square that with the logic that makes sense to me. And no amount of logic about why Python 3 is better is going to solve the problem of the two of them being unhappy. They are speaking from experience working with the actual product. I'm not trying to convince anyone that Python 3 is good or bad. I'm talking about our approach to unhappy and influential customers. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
>> Most of the complaints about Py3 are "it's harder to get something >> started (or port from Py2)". My answer is that it's easier to get >> something finished. > > I like all of this logic, it makes sense to me. But Armin and Kenneth have > more experience than I do actually writing networking software. They are > both very smart and very willing to do a ton of work. And both are unhappy. > I don't know how to square that with the logic that makes sense to me. > > And no amount of logic about why Python 3 is better is going to solve the > problem of the two of them being unhappy. They are speaking from experience > working with the actual product. +1, well-said. I hope you'll see my comments on the thread on the "bytestring type". This issue also goes back to the schism in 2004 from the VPython folks over floating point. Again the ***whole*** issue is ignoring the relationship between your abstractions and your concrete architectural implementations. I honestly think Python3 will have to be regressed despite all the circle jerking about how "everyone's moving to Python 3 now". I see how I was inadequately explaining the whole issue by using high-level concepts like "models of computation", but the comments on the aforementioned thread go right down to the heart of the issue. markj -- https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
On Sun, Jan 5, 2014 at 4:46 PM, Ethan Furman wrote: > While I don't agree with his assessment of Python 3 in total, I definitely > feel his pain with regards to bytestrings in Py3 -- because they don't > exist. 'bytes' /looks/ like a bytestring, but really it's just a bunch of > integers: > > --> b'abc > 'b'abc' > --> b'abc'[1] > 98 > > Maybe for 3.5 somebody *cough* will make a bytestring type for those of us > who have to support the lower-level protocols... I don't see anything wrong with the new bytes type, including the example above. I wrote a backup program that used bytes or str's (3.x or 2.x respectively), and they both worked fine for that. I had to code around some limited number of surprises, but they weren't substantive problems, they were just differences. The argument seems to be "3.x doesn't work the way I'm accustomed to, so I'm not going to use it, and I'm going to shout about it until others agree with me." And yes, I read Armin's article - it was pretty long Also, I never once wrote a program to use 2.x's unicode type. I always used str. It was important to make str handle unicode, to get people (like me!) to actually use unicode. Two modules helped me quite a bit with backshift, the backup program I mentioned: http://stromberg.dnsalias.org/~dstromberg/backshift/documentation/html/python2x3-module.html http://stromberg.dnsalias.org/~dstromberg/backshift/documentation/html/bufsock-module.html python2x3 is tiny, and similar in spirit to the popular six module. bufsock is something I wrote years ago that enables consistent I/O on sockets, files or file descriptors; 2.x or 3.x. HTH -- https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
On 01/05/2014 05:48 PM, Chris Angelico wrote: On Mon, Jan 6, 2014 at 12:16 PM, Ned Batchelder wrote: So now we have two revered developers vocally having trouble with Python 3. You can dismiss their concerns as niche because it's only network programming, but that would be a mistake. IMO, network programming (at least on the internet) is even more Py3's domain (pun not intended). The issue is not how to handle text, the issue is how to handle ascii when it's in a bytes object. Using my own project [1] as a reference: good ol' dbf files -- character fields, numeric fields, logic fields, time fields, and of course the metadata that describes these fields and the dbf as a whole. The character fields I turn into unicode, no sweat. The metadata fields are simple ascii, and in Py2 something like `if header[FIELD_TYPE] == 'C'` did the job just fine. In Py3 that compares an int (67) to the unicode letter 'C' and returns False. For me this is simply a major annoyance, but I only have a handful of places where I have to deal with this. Dealing with protocols where bytes is the norm and embedded ascii is prevalent -- well, I can easily imagine the nightmare. The most unfortunate aspect is that even if we did "fix" it in 3.5, it wouldn't help any body who has to support multiple versions... unless, of course, a backport could also be made. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
On Mon, Jan 6, 2014 at 1:23 PM, Ethan Furman wrote: > The metadata fields are simple ascii, and in Py2 something like `if > header[FIELD_TYPE] == 'C'` did the job just fine. In Py3 that compares an > int (67) to the unicode letter 'C' and returns False. For me this is simply > a major annoyance, but I only have a handful of places where I have to deal > with this. Dealing with protocols where bytes is the norm and embedded > ascii is prevalent -- well, I can easily imagine the nightmare. It can't be both things. It's either bytes or it's text. If it's text, then decoding it as ascii will give you a Unicode string; if it's small unsigned integers that just happen to correspond to ASCII values, then I would say the right thing to do is integer constants - or, in Python 3.4, an integer enumeration: >>> socket.AF_INET >>> socket.AF_INET == 2 True I'm not sure what FIELD_TYPE of 'C' means, but my guess is that it's a CHAR field. I'd just have that as the name, something like: CHAR = b'C'[0] if header[FIELD_TYPE] == CHAR: # handle char field If nothing else, this would reduce the number of places where you actually have to handle this. Plus, the code above will work on many versions of Python (I'm not sure how far back the b'' prefix is allowed - probably 2.6). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Postfix conditionals
On 1/5/2014 3:24 PM, Göktuğ Kayaalp wrote:
Hi,
AFAIK, we do not have "postfix conditionals" in Python, i.e. a condition
appended to a
statement, which determines whether the statement runs or not:
py> for i in [False]:
... break if not i
The above piece of code is equivalent to this in Python:
py> for i in [False]:
...if not i
...break
I believe that the first example is superior to the second example when
the two is compared
for readability and intuitiveness. We already have a ternary statement
'conditional expression', which happens to be a ternary as opposed to
binary expression.
that looks similar,
py> print('hi') if True else None
so I reckon there would be no breakage in old code if this kind of
syntax was added. Ruby has
this, and AFAIK Perl also does.
I lack the knowledge of whether the community has opinions on this kind
of notation,
In general, negative on pure duplication. Guido has said he strongly
dislikes the perl reverse if.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
In article , Mark Janssen wrote: > I honestly think Python3 will have to be regressed despite all the > [obscenity elided] about how "everyone's moving to Python 3 now". This forum has seen a lot honest disagreement about issues, sometimes hotly debated. That's OK. Sometimes the discussion has not been completely professional, which is less than wonderful, but everything can't always be wonderful. There is absolutely no reason, however, to resort to profanity. That's just unacceptable. -- https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
In article , Chris Angelico wrote: > It can't be both things. It's either bytes or it's text. I've never used Python 3, so forgive me if these are naive questions. Let's say you had an input stream which contained the following hex values: $ hexdump data 000 d7 a8 a3 88 96 95 That's EBCDIC for "Python". What would I write in Python 3 to read that file and print it back out as utf-8 encoded Unicode? Or, how about a slightly different example: $ hexdump data 000 43 6c 67 75 62 61 That's "Python" in rot-13 encoded ascii. How would I turn that into cleartext Unicode in Python 3? -- https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
On 1/5/2014 8:16 PM, Ned Batchelder wrote: OK, let's see what we got from three core developers on this list: To me, the following is a partly unfair summary. - Antoine dismissed the post as "a rant". He called it a rant while acknowledging that there is a unsolved issue with transforms. Whether he was 'dismissing' it or not, I do not know. Antoine also noted that there does not seem to be anything new in this post that Armin has not said before. Without reading in detail, I had the same impression. - Terry took issue with three claims made, and ended with, "I suspect there are other basic errors, but I mostly quit reading at this point." You are discouraged that I quit reading? How much sludge do you expect me to wade through? If Armin wants my attention (and I do not think he does), it is *his* responsibility to write in a readable manner. But I read a bit more and found a 4th claim to 'take issue with' (to be polite): "only about 3% of all Python developers using Python 3 properly" with a link to http://alexgaynor.net/2014/jan/03/pypi-download-statistics/ The download statistics say nothing about the percent of all Python developers using Python 3, let alone properly, and Alex Gaynor makes no such claim as Armin did. I would not be surprised if a majority of Python users have never downloaded from pypi. What I do know from reading the catalog-sig (pypi) list for a couple of years is that there are commercial developers who use pypi heavily to update 1000s of installations and that they drive the development of the pypi infrastructure. I strongly suspect that they strongly skew the download statistics. Dubious claim 5 is this: "For 97% of us, Python 2 is our beloved world for years to come". For Armin's narrow circle, that may be true, but I suspect that more than 3% of Python programmers have never written Python2 only code. - Serhiy made a sarcastic comment comparing Python 3's bytes/unicode handling with Python 2's int/str handling, implying that since int/str wasn't a problem, then bytes/unicode isn't either. Serhiy's point was about the expectation of implicit conversion (int/str) versus (bytes/str) and the complaint about removal of implicit conversion. I suspect that part of his point is that if we never had implicit bytes/unicode conversion, it would not be expected. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
On 2014-01-05 23:24, Roy Smith wrote:
> $ hexdump data
> 000 d7 a8 a3 88 96 95
>
> That's EBCDIC for "Python". What would I write in Python 3 to read
> that file and print it back out as utf-8 encoded Unicode?
>
> Or, how about a slightly different example:
>
> $ hexdump data
> 000 43 6c 67 75 62 61
>
> That's "Python" in rot-13 encoded ascii. How would I turn that
> into cleartext Unicode in Python 3?
tim@laptop$ python3
Python 3.2.3 (default, Feb 20 2013, 14:44:27)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> s1 = b'\xd7\xa8\xa3\x88\x96\x95'
>>> s1.decode('ebcdic-cp-be')
'Python'
>>> s2 = b'\x43\x6c\x67\x75\x62\x61'
>>> from codecs import getencoder
>>> getencoder("rot-13")(s2.decode('utf-8'))[0]
'Python'
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
In article ,
Tim Chase wrote:
> On 2014-01-05 23:24, Roy Smith wrote:
> > $ hexdump data
> > 000 d7 a8 a3 88 96 95
> >
> > That's EBCDIC for "Python". What would I write in Python 3 to read
> > that file and print it back out as utf-8 encoded Unicode?
> >
> > Or, how about a slightly different example:
> >
> > $ hexdump data
> > 000 43 6c 67 75 62 61
> >
> > That's "Python" in rot-13 encoded ascii. How would I turn that
> > into cleartext Unicode in Python 3?
>
>
> tim@laptop$ python3
> Python 3.2.3 (default, Feb 20 2013, 14:44:27)
> [GCC 4.7.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> s1 = b'\xd7\xa8\xa3\x88\x96\x95'
> >>> s1.decode('ebcdic-cp-be')
> 'Python'
> >>> s2 = b'\x43\x6c\x67\x75\x62\x61'
> >>> from codecs import getencoder
> >>> getencoder("rot-13")(s2.decode('utf-8'))[0]
> 'Python'
>
> -tkc
Thanks. But, I see I didn't formulate my problem statement well. I was
(naively) assuming there wouldn't be a built-in codec for rot-13. Let's
assume there isn't; I was trying to find a case where you had to treat
the data as integers in one place and text in another. How would you do
that?
--
https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
On Mon, Jan 6, 2014 at 3:24 PM, Roy Smith wrote:
> I've never used Python 3, so forgive me if these are naive questions.
> Let's say you had an input stream which contained the following hex
> values:
>
> $ hexdump data
> 000 d7 a8 a3 88 96 95
>
> That's EBCDIC for "Python". What would I write in Python 3 to read that
> file and print it back out as utf-8 encoded Unicode?
*deletes the two paragraphs that used to be here* Turns out Python 3
_does_ have an EBCDIC decoder... but it's not called EBCDIC.
>>> b"\xd7\xa8\xa3\x88\x96\x95".decode("cp500")
'Python'
This sounds like a good one for getting an alias, either "ebcdic" or
"EBCDIC". I didn't know that this was possible till I googled the
problem and saw someone else's solution.
To print that out as UTF-8, just decode and then encode:
>>> b"\xd7\xa8\xa3\x88\x96\x95".decode("cp500").encode("utf-8")
b'Python'
In the specific case of files on the disk, you could open them with
encodings specified, in which case you don't need to worry about the
details.
with open("data",encoding="cp500") as infile:
with open("data_utf8","w",encoding="utf-8") as outfile:
outfile.write(infile.read())
Of course, this is assuming that Unicode has a perfect mapping for
every EBCDIC character. I'm not familiar enough with EBCDIC to be sure
that that's true, but I strongly suspect it is. And if it's not,
you'll get an exception somewhere along the way, so you'll know
something's gone wrong. (In theory, a "transcode" function might be
able to give you a warning before it even sees your data -
transcode("utf-8", "iso-8859-3") could alert you to the possibility
that not everything in the source character set can be encoded. But
that's a pretty esoteric requirement.)
> Or, how about a slightly different example:
>
> $ hexdump data
> 000 43 6c 67 75 62 61
>
> That's "Python" in rot-13 encoded ascii. How would I turn that into
> cleartext Unicode in Python 3?
That's one of the points that's under dispute. Is rot13 a
bytes<->bytes encoding, or is it str<->str, or is it bytes<->str? The
issue isn't clear. Personally, I think it makes good sense as a
str<->str translation, which would mean that the process would be
somewhat thus:
>>> rot13={}
>>> for i in range(13):
rot13[65+i]=65+i+13
rot13[65+i+13]=65+i
rot13[97+i]=97+i+13
rot13[97+i+13]=97+i
>>> data = b"\x43\x6c\x67\x75\x62\x61" # is there an easier way to turn a hex
>>> dump into a bytes literal?
>>> data.decode().translate(rot13)
'Python'
This is treating rot13 as a translation of Unicode codepoints to other
Unicode codepoints, which is different from an encode operation (which
takes abstract Unicode data and produces concrete bytes) or a decode
operation (which does the reverse). But this is definitely a grey
area. It's common for cryptographic algorithms to work with bytes,
meaning that their "decoded" text is still bytes. (Or even less than
bytes. The famous Enigma machines from World War II worked with the 26
letters as their domain and range.) Should the Python codecs module
restrict itself to the job of translating between bytes and str, or is
it a tidy place to put those other translations as well?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: "More About Unicode in Python 2 and 3"
On Mon, Jan 6, 2014 at 3:49 PM, Roy Smith wrote: > Thanks. But, I see I didn't formulate my problem statement well. I was > (naively) assuming there wouldn't be a built-in codec for rot-13. Let's > assume there isn't; I was trying to find a case where you had to treat > the data as integers in one place and text in another. How would you do > that? I assumed that you would have checked that one, and answered accordingly :) Though I did dig into the EBCDIC part of the question. My thinking is that, if you're working with integers, you probably mean either bytes (so encode it before you do stuff - typical for crypto) or codepoints / Unicode ordinals (so use ord()/chr()). In other languages there are ways to treat strings as though they were arrays of integers (lots of C-derived languages treat 'a' as 97 and "a"[0] as 97 also; some extend this to the full Unicode range), and even there, I almost never actually use that identity much. There's only one case that I can think of where I did a lot of string<->integer-array transmutation, and that was using a diff function that expected an integer array - if the transformation to and from strings hadn't been really easy, that function would probably have been written to take strings. The Py2 str.translate() method was a little clunky to use, but presumably fast to execute - you build up a lookup table and translate through that. The Py3 equivalent takes a dict mapping the from and to values. Pretty easy to use. And it lets you work with codepoints or strings, as you please. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Reg : Creating a exe file from pyinstaller of python application
Hi, I'm creating GUI using python gtk, and which uses external library gtk , M2Crypto I want make executable file by using pyinstaller, Which is not including external library How to make external library include into executable file . Can you give any suggestion how to import external library in make of executable file in windows xp. Thanks & With Regards Prapulla -- https://mail.python.org/mailman/listinfo/python-list
Re: Blog "about python 3"
On 06/01/2014 01:54, Chris Angelico wrote:
On Mon, Jan 6, 2014 at 12:23 PM, Steven D'Aprano
wrote:
(However, to the extent that Amazon has gained monopoly power over the book
market, that reasoning may not apply. Amazon is not *technically* a
monopoly, but they are clearly well on the way to becoming one, at which
point the customer has no effective choice and the market is no longer
free.)
They don't need a monopoly on the whole book market, just on specific
books - which they did have, in the cited case. I actually asked the
author (translator, really - it's a translation of "Alice in
Wonderland") how he would prefer me to buy, as there are some who sell
on Amazon and somewhere else. There was no alternative to Amazon, ergo
no choice and the market was not free. Like so many things, one choice
("I want to buy Ailice's Anters in Ferlielann") mandates another
("Must buy through Amazon").
I don't know what it cost Amazon to ship me two copies of a book, but
still probably less than they got out of me, so they're still ahead.
Even if they lost money on this particular deal, they're still way
ahead because of all the people who decide it's not worth their time
to spend an hour or so trying to get a replacement. So yep, this
policy is serving Amazon fairly well.
ChrisA
So much for my "You never know, we might even end up with a thread
whereby the discussion is Python, the whole Python and nothing but the
Python." :)
--
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
function to split strings and lists on predicate
I came across this over the weekend http://paddy3118.blogspot.co.uk/2013/10/unifying-pythons-string-and-list.html. I couldn't come up with a solution to the fsplit function that seemed in any way cleaner. What can our nest of avid Pythonistas come up with? -- 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: Postfix conditionals
On 06-01-2014 03:40, Rhodri James wrote: On Sun, 05 Jan 2014 20:24:53 -, Göktuğ Kayaalp wrote: AFAIK, we do not have "postfix conditionals" in Python, i.e. a condition appended to a statement, which determines whether the statement runs or not: py> for i in [False]: ... break if not i The above piece of code is equivalent to this in Python: py> for i in [False]: ...if not i ...break I believe that the first example is superior to the second example when the two is compared for readability and intuitiveness. In my past life as a newcomer to Perl, I thought this too. Postfix conditionals read more like English, so they would be easier to take in and understand. As I wrote more code, I discovered that this didn't seem to be the case; except in very simple cases, I had to mentally transpose the conditional back to the start of the statement to properly comprehend what was going on and what the results would be for my sample data. It looks like a good idea, but I don't think it works that well in practice. Thanks for the input! I'd be quite interested in examples which required you to "mentally transpose the conditional back to the start of the statement", by the way. gk -- https://mail.python.org/mailman/listinfo/python-list
