On Feb 18, 2010, at 12:20 AM, alex23 wrote:
MRAB wrote:
Python 3.0 had a relatively short run before it was superseded by
Python
3.1 due to certain issues, so, IMHO, I wouldn't worry about it unless
someone especially requests/requires it.
And even then, I'd just tell them I accept patche
MRAB wrote:
> Python 3.0 had a relatively short run before it was superseded by Python
> 3.1 due to certain issues, so, IMHO, I wouldn't worry about it unless
> someone especially requests/requires it.
And even then, I'd just tell them I accept patches :)
--
http://mail.python.org/mailman/listin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philip Semanchuk wrote:
> is Python 3.0 seeing use in production
> anywhere, or did most of the Python world move to 3.1 as soon as it was
> released?
Python 3.0 has been end of lifed:
http://www.python.org/download/releases/3.0.1/
Consequently no
Philip Semanchuk wrote:
Hi all,
I'm the author of an extension (posix_ipc) that works under Python 2.4 -
2.6. I have a version that works under Python 2.4-2.6 and 3.1 and I
would like to release it, but it doesn't work under Python 3.0. I could
hack up Python 3.0-specific workarounds, but I'm
Alan G Isaac wrote:
Using the 3.1 Windows installer, I chose that I did not
want the extensions registered, and the installer
unregistered the .py and .pyw extensions (which I had wanted
to keep associated with Python 2.6).
Is this intentional?
I suspect not, but Martin is the one to answer.
I
Using the 3.1 Windows installer, I chose that I did not
want the extensions registered, and the installer
unregistered the .py and .pyw extensions (which I had wanted
to keep associated with Python 2.6).
Is this intentional?
Alan Isaac
PS I already fixed the problem. My question
is about intent
In article <49dcc2df$0$29421$4c5ec...@fe1.usenet.com>,
Jim Garrison wrote:
>
>I emailed the webmaster but have received no response.
Several people have sent e-mail about this; sorry, we haven't had time
for individual responses.
--
Aahz (a...@pythoncraft.com) <*> http://www.p
On Wed, Apr 8, 2009 at 11:28 AM, Jim Garrison wrote:
> Jim Garrison wrote:
>
>> Ye Liu wrote:
>>
>>> On Apr 6, 6:33 pm, Jim Garrison wrote:
>>>
I notice the online docs (at docs.python.org/3.0/index.html) were
updated today. It seems some of the top-level pages, like
Tutorial, "U
"Jim Garrison"
> Jim Garrison wrote:
> > Ye Liu wrote:
> >> On Apr 6, 6:33 pm, Jim Garrison wrote:
> >>> I notice the online docs (at docs.python.org/3.0/index.html) were
> >>> updated today. It seems some of the top-level pages, like
> >>> Tutorial, "Using Python", "Language Reference" are tru
Thanks a lot for all the responses. I'll move back to Python 2.5 for
compatibility with SciPY and some other third party packages.
I'll leave the compilation process for some other day, for now I'm a
happy user, mayve In the future I would like to contribute to the
developmental process..
--
http:/
Quoth Christian Heimes :
> thomasvang...@gmail.com schrieb:
> > I just recently learned python, I'm using it mainly to process huge
> > <5GB txt files of ASCII information about DNA. I've decided to learn
> > 3.0, but maybe I need to step back to 2.6?
> >
> > I'm getting exceedingly frustrated by
thomasvang...@gmail.com wrote:
> C:\python30> patch -p0 < fileio_buffer.patch
> The patch command is not recognized..
You need the 'patch' program first. Further, you will need a C compiler. If
you don't know how to compile from sources, I would postpone patching
sources to after learning that.
>
thomasvang...@gmail.com schrieb:
> I just recently learned python, I'm using it mainly to process huge
> <5GB txt files of ASCII information about DNA. I've decided to learn
> 3.0, but maybe I need to step back to 2.6?
>
> I'm getting exceedingly frustrated by the slow file IO behaviour of
> pytho
Martin v. Löwis wrote:
But the document also mentions that the result is not strictly
"undefined" but "reproducable undetermined".
What specific document are you looking at, and where specifically
does it say that? I can't believe that the quotation marks indicate
an actual quote, in particular
towit...@gmail.com wrote:
Hello,
In the 3.0 changes list there is mentioned that "<"-compares are not
supported anymore if the compared types are different (except
numbers). Like
42 < "Hello"
did return True of False depending on the implementation but is now a
TypeError.
But the document als
> But the document also mentions that the result is not strictly
> "undefined" but "reproducable undetermined".
What specific document are you looking at, and where specifically
does it say that? I can't believe that the quotation marks indicate
an actual quote, in particular because "reproducible
On Jan 22, 2:17 am, a...@pythoncraft.com (Aahz) wrote:
> In article
> <313a27f9-c655-4fc4-a8e3-568a4283b...@f40g2000pri.googlegroups.com>,
>
> ag73 wrote:
>
> > form = urllib.parse.parse_qs(qs, keep_blank_values=1)
>
> >However, the last line of code that calls parse_qs causes
In article <313a27f9-c655-4fc4-a8e3-568a4283b...@f40g2000pri.googlegroups.com>,
ag73 wrote:
>
> form = urllib.parse.parse_qs(qs, keep_blank_values=1)
>
>However, the last line of code that calls parse_qs causes the
>following exception to be thrown:
>
>
>Type str doesn't sup
On Jan 14, 9:56 am, Andy Grove wrote:
> On Jan 13, 3:08 pm, John Machin wrote:
>
> > Please show the full traceback.
>
> John,
>
> Thanks. Here it is:
>
> File "/Library/Frameworks/Python.framework/Versions/3.0/lib/
> python3.0/socketserver.py", line 281, in _handle_request_noblock
> self.p
I don't fully understand this but if I pass in "str(qs)" instead of
"qs" then the call works. However, qs is returned from file.read()
operation so shouldn't that be a string already?
In case it's not already obvious, I am new to Python :-) .. so I'm
probably missing something here.
--
http://mail
On Jan 13, 3:08 pm, John Machin wrote:
> Please show the full traceback.
John,
Thanks. Here it is:
File "/Library/Frameworks/Python.framework/Versions/3.0/lib/
python3.0/socketserver.py", line 281, in _handle_request_noblock
self.process_request(request, client_address)
File "/Library/
On Jan 14, 6:54 am, ag73 wrote:
> Hi,
>
> I am trying to parse data posted to a Python class that extends
> http.server.BaseHTTPRequestHandler. Here is the code I am using:
>
> def do_POST(self):
> ctype, pdict = cgi.parse_header(self.headers['Content-Type'])
>
On Jan 6, 11:46 am, Rob Williscroft wrote:
> Matimus wrote in news:2a3d6700-85f0-4861-84c9-9f269791f044
> Searching (AKA googling) for: nonlocal site:bugs.python.org
> leads to:http://bugs.python.org/issue4199
>
> Rob.
> --http://www.victim-prime.dsl.pipex.com/
Doh. I looked at the PEP and the 3
On Jan 6, 11:10 am, Matimus wrote:
> `nonlocal` should behave just like `global` does. It doesn't support
> that syntax either. So, yes it was intentional. No, there probably is
> no plan to support it in a later release.
>
> Matt
>From my perspective, that's an unfortunate decision and I questi
Matimus wrote in news:2a3d6700-85f0-4861-84c9-9f269791f044
@f40g2000pri.googlegroups.com in comp.lang.python:
> On Jan 6, 5:31 am, Casey wrote:
>> In PEP 3104 the nonlocal statement was proposed and accepted for
>> implementation in Python 3.0 for access to names in outer scopes. The
>> proposed
On Jan 6, 5:31 am, Casey wrote:
> In PEP 3104 the nonlocal statement was proposed and accepted for
> implementation in Python 3.0 for access to names in outer scopes. The
> proposed syntax included an optional assignment or augmented
> assignment to the outer name, such as:
>
> nonlocal x += 1
>
Just resolved the issue (turned out to be an issue with linked ncurses
libraries). If others run into this discussion of the solution can be found
at:
http://bugs.python.org/issue4787
Cheers! -Damian
On Mon, Dec 29, 2008 at 10:30 PM, Damian Johnson wrote:
> It seems as if the curses module in P
It seems as if the curses module in Python 3.0 isn't respecting the system's
preferred encoding (utf-8) which was set via:
locale.setlocale(locale.LC_ALL, '')
The purpose of this was described at the top of '
http://docs.python.org/dev/3.0/library/curses.html#module-curses'. The
getlocale function
Assuming those survived the switch to 3.0, you can use site.py und
sys.displayhook to customize to the old behaviour (i.e. change it to a
version using ascii instead of repr). Since this only affects
interactive use, it's also no problem for portability of code, unlike
"solutions" like forcing the
> It's unfortunate that the default behaviour isn't
> optimal at the interactive prompt for some configurations, though.
As I said, it's a trade-off. The alternative, if it was the default,
wouldn't be optimal at the interactive prompt for some other
configurations.
In particular, users of non-la
On 14 Des, 22:13, "Martin v. Löwis" wrote:
> > But shouldn't the production of an object's representation via repr be
> > a "safe" operation?
>
> It's a trade-off. It should also be legible.
Right. I can understand that unlike Python 2.x, a representation of a
string in Python 3.x (whose equivale
On Mon, Dec 15, 2008 at 9:03 AM, Fuzzyman wrote:
> It seems to me to be a generally accepted term when an application
> stops due to an unhandled error to say that it crashed.
it == application
Yes.
#!/usr/bin/env python
from traceback import format_exc
def foo():
print
> That's an interesting definition of crash. You're just like saying: "C
> has crashed because I made a bug in my program". In this context, it is
> your program that crashes, not python nor C, it is misleading to say so.
>
> It will be python's crash if:
> 1. Python 'segfault'ed
> 2. Python inter
> But shouldn't the production of an object's representation via repr be
> a "safe" operation?
It's a trade-off. It should also be legible.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
On 14 Des, 05:46, "Martin v. Löwis" wrote:
>
> Yes. If you want a display that is guaranteed to work on your terminal,
> use the ascii() builtin function.
But shouldn't the production of an object's representation via repr be
a "safe" operation? That is, the operation should always produce a
resu
> "Sure" as in "sure, it was not intended behaviour"?
It was intended behavior, and still is in 3.0.
>> This behavior has not changed. It still uses repr().
>>
>> Of course, the string type has changed in 3.0, and now uses a different
>> definition of repr.
>
> So was the above-reported non-cras
"John Machin" wrote in message
news:a8cd683f-853d-4665-bee4-7a0bdb841...@c36g2000prc.googlegroups.com...
On Dec 14, 9:20 am, "Martin v. Löwis" wrote:
> >> This is intended behavior.
>
> > I see. That means that the behaviour in Python 1.6 to 2.6 (i.e.
> > encoding the text using the repr() fu
On Sat, 13 Dec 2008 14:09:04 -0800, John Machin wrote:
> On Dec 14, 8:07 am, "Chris Rebert" wrote:
>> On Sat, Dec 13, 2008 at 12:28 PM, John Machin
>> wrote:
>>
>> > Python 2.6.1 (r261:67517, Dec 4 2008, 16:51:00) [MSC v.1500 32 bit
>> > (Intel)] on win32
>> > Type "help", "copyright", "credits
On Dec 14, 9:20 am, "Martin v. Löwis" wrote:
> >> This is intended behavior.
>
> > I see. That means that the behaviour in Python 1.6 to 2.6 (i.e.
> > encoding the text using the repr() function (as then defined) was not
> > intended behaviour?
>
> Sure.
"Sure" as in "sure, it was not intended be
>> This is intended behavior.
>
> I see. That means that the behaviour in Python 1.6 to 2.6 (i.e.
> encoding the text using the repr() function (as then defined) was not
> intended behaviour?
Sure. This behavior has not changed. It still uses repr().
Of course, the string type has changed in 3.0
On Dec 14, 8:07 am, "Chris Rebert" wrote:
> On Sat, Dec 13, 2008 at 12:28 PM, John Machin wrote:
>
> > Python 2.6.1 (r261:67517, Dec 4 2008, 16:51:00) [MSC v.1500 32 bit
> > (Intel)] on win32
> > Type "help", "copyright", "credits" or "license" for more information.
> x = u'\u9876'
> x
On Sat, Dec 13, 2008 at 12:28 PM, John Machin wrote:
>
> Python 2.6.1 (r261:67517, Dec 4 2008, 16:51:00) [MSC v.1500 32 bit
> (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
x = u'\u9876'
x
> u'\u9876'
>
> # As expected
>
> Python 3.0 (r30:6750
2008/12/13 John Machin :
>
> Python 2.6.1 (r261:67517, Dec 4 2008, 16:51:00) [MSC v.1500 32 bit
> (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
x = u'\u9876'
x
> u'\u9876'
>
> # As expected
>
> Python 3.0 (r30:67507, Dec 3 2008, 20:14:27) [MS
On Dec 8, 2:05 am, Johannes Bauer <[EMAIL PROTECTED]> wrote:
> John Machin schrieb:
>
> > He did. Ugly stuff using readline() :-) Should still work, though.
>
> Well, well, I'm a C kinda guy used to while (fgets(b, sizeof(b), f))
> kinda loops :-)
>
> But, seriously - I find that whole "while True:
On Sun, 07 Dec 2008 16:05:53 +0100
Johannes Bauer <[EMAIL PROTECTED]> wrote:
> But, seriously - I find that whole "while True:" and "if line == """
> construct ugly as hell, too. How can reading a file line by line be
> achieved in a more pythonic kind of way?
for line in open(filename):
--
D
John Machin schrieb:
> He did. Ugly stuff using readline() :-) Should still work, though.
Well, well, I'm a C kinda guy used to while (fgets(b, sizeof(b), f))
kinda loops :-)
But, seriously - I find that whole "while True:" and "if line == """
construct ugly as hell, too. How can reading a file
On Dec 7, 8:15 pm, Terry Reedy <[EMAIL PROTECTED]> wrote:
> John Machin wrote:
> > Here's the scoop: It's a bug in the newline handling (in io.py, class
> > IncrementalNewlineDecoder, method decode). It reads text files in 128-
> > byte chunks. Converting CR LF to \n requires special case handling
John Machin wrote:
Here's the scoop: It's a bug in the newline handling (in io.py, class
IncrementalNewlineDecoder, method decode). It reads text files in 128-
byte chunks. Converting CR LF to \n requires special case handling
when '\r' is detected at the end of the decoded chunk n in case
there
On Dec 7, 9:34 am, John Machin <[EMAIL PROTECTED]> wrote:
> On Dec 7, 9:01 am, David Bolen <[EMAIL PROTECTED]> wrote:
>
> > Johannes Bauer <[EMAIL PROTECTED]> writes:
> > > This is very strange - when using "utf16", endianness should be detected
> > > automatically. When I simply truncate the trail
On Dec 7, 9:01 am, David Bolen <[EMAIL PROTECTED]> wrote:
> Johannes Bauer <[EMAIL PROTECTED]> writes:
> > This is very strange - when using "utf16", endianness should be detected
> > automatically. When I simply truncate the trailing zero byte, I receive:
>
> Any chance that whatever you used to "
Johannes Bauer <[EMAIL PROTECTED]> writes:
> This is very strange - when using "utf16", endianness should be detected
> automatically. When I simply truncate the trailing zero byte, I receive:
Any chance that whatever you used to "simply truncate the trailing
zero byte" also removed the BOM at th
On Dec 7, 6:20 am, "Mark Tolonen" <[EMAIL PROTECTED]> wrote:
> "Johannes Bauer" <[EMAIL PROTECTED]> wrote in message
>
> news:[EMAIL PROTECTED]
>
>
>
> >John Machin schrieb:
> >> On Dec 6, 5:36 am, Johannes Bauer <[EMAIL PROTECTED]> wrote:
> >>> So UTF-16 has an explicit EOF marker within the text?
"Johannes Bauer" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
John Machin schrieb:
On Dec 6, 5:36 am, Johannes Bauer <[EMAIL PROTECTED]> wrote:
So UTF-16 has an explicit EOF marker within the text? I cannot find one
in original file, only some kind of starting sequence I suppose
Johannes Bauer wrote:
[EMAIL PROTECTED] schrieb:
2 problems: endianness and trailing zer byte.
This works for me:
This is very strange - when using "utf16", endianness should be detected
automatically. When I simply truncate the trailing zero byte, I receive:
Traceback (most recent call last
John Machin schrieb:
> On Dec 6, 5:36 am, Johannes Bauer <[EMAIL PROTECTED]> wrote:
>> So UTF-16 has an explicit EOF marker within the text? I cannot find one
>> in original file, only some kind of starting sequence I suppose
>> (0xfeff). The last characters of the file are 0x00 0x0d 0x00 0x0a,
>>
[EMAIL PROTECTED] schrieb:
> 2 problems: endianness and trailing zer byte.
> This works for me:
This is very strange - when using "utf16", endianness should be detected
automatically. When I simply truncate the trailing zero byte, I receive:
Traceback (most recent call last):
File "./modify.py
On Dec 4, 9:06 pm, illume <[EMAIL PROTECTED]> wrote:
> Cool thanks Benjamin!
>
> Maybe it should be in a wiki as well? So that as people convert their
> modules we can add notes as well.
>
> I started a wiki with that in mind here:http://wiki.python.org/moin/cporting
>
> It'd be good if there was
John Machin wrote:
On Dec 6, 10:35 am, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
On Fri, 05 Dec 2008 12:00:59 -0700, Joe Strout wrote:
So UTF-16 has an explicit EOF marker within the text?
No, it does not. I don't know what Terry's thinking of there, but text
files do not
On Dec 6, 10:35 am, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Fri, 05 Dec 2008 12:00:59 -0700, Joe Strout wrote:
> >> So UTF-16 has an explicit EOF marker within the text?
>
> > No, it does not. I don't know what Terry's thinking of there, but text
> > files do not have an
On Fri, 05 Dec 2008 12:00:59 -0700, Joe Strout wrote:
>> So UTF-16 has an explicit EOF marker within the text?
>
> No, it does not. I don't know what Terry's thinking of there, but text
> files do not have any EOF marker. They start at the beginning
> (sometimes including a byte-order mark), an
On Dec 6, 5:36 am, Johannes Bauer <[EMAIL PROTECTED]> wrote:
> So UTF-16 has an explicit EOF marker within the text? I cannot find one
> in original file, only some kind of starting sequence I suppose
> (0xfeff). The last characters of the file are 0x00 0x0d 0x00 0x0a,
> simple \r\n line ending.
S
Joe Strout wrote:
On Dec 5, 2008, at 11:36 AM, Johannes Bauer wrote:
I suspect that '?' after \n (\u0a00) is indicates not 'question-mark'
but 'uninterpretable as a utf16 character'. The traceback below
confirms that. It should be an end-of-file marker and should not be
passed to Python. I s
On Dec 5, 3:25 pm, Johannes Bauer <[EMAIL PROTECTED]> wrote:
> Hello group,
>
> I'm having trouble reading a utf-16 encoded file with Python3.0. This is
> my (complete) code:
>
> #!/usr/bin/python3.0
>
> class AddressBook():
> def __init__(self, filename):
> f = open(filenam
On Dec 5, 2008, at 11:36 AM, Johannes Bauer wrote:
I suspect that '?' after \n (\u0a00) is indicates not 'question-mark'
but 'uninterpretable as a utf16 character'. The traceback below
confirms that. It should be an end-of-file marker and should not be
passed to Python. I strongly suspect tha
Terry Reedy schrieb:
> Johannes Bauer wrote:
>> Hello group,
>>
>> I'm having trouble reading a utf-16 encoded file with Python3.0. This is
>> my (complete) code:
>
> what OS. This is often critical when you have a problem interacting
> with the OS.
It's a 64-bit Linux, currently running:
Linux
Johannes Bauer wrote:
Hello group,
I'm having trouble reading a utf-16 encoded file with Python3.0. This is
my (complete) code:
what OS. This is often critical when you have a problem interacting
with the OS.
#!/usr/bin/python3.0
class AddressBook():
def __init__(self, filename):
"J Kenneth King" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> It probably means what it says: that the input file contains characters
> it cannot read using the specified encoding.
That was my first thought. However it appears that there is an off by one
error somewhere in the
J Kenneth King schrieb:
> It probably means what it says: that the input file contains characters
> it cannot read using the specified encoding.
No, it doesn't. The file is just fine, just as the example.
> Are you generating the file from python using a file object with the
> same encoding? If
Johannes Bauer <[EMAIL PROTECTED]> writes:
> Traceback (most recent call last):
> File "./modify.py", line 12, in
> a = AddressBook("2008_11_05_Handy_Backup.txt")
> File "./modify.py", line 7, in __init__
> line = f.readline()
> File "/usr/local/lib/python3.0/io.py", line 1807, in r
Cool thanks Benjamin!
Maybe it should be in a wiki as well? So that as people convert their
modules we can add notes as well.
I started a wiki with that in mind here:
http://wiki.python.org/moin/cporting
It'd be good if there was a link from the 2to3 docs, and in the C API
docs to either/both
On Dec 4, 7:45 pm, illume <[EMAIL PROTECTED]> wrote:
> Hi,
>
> are there migration tools for C API migration to python 3?
>
> I'm sure there must be some code somewhere to help change stuff over
> right?
>
> I don't see any docs for migrating code from 2.x to 3.x
> either:http://docs.python.org/3.
On Mon, 24 Nov 2008 10:42:41 +, Duncan Grisby wrote:
> Again, this is just an example. As I say, in the real application, the
> data has come from a dynamically-typed database. There's no easy way to
> coerce all the items to the same type, because the application doesn't
> know up-front what
On Mon, 24 Nov 2008 17:33:50 +, Tim Rowe wrote:
> 2008/11/24 Aahz <[EMAIL PROTECTED]>:
>
>> (I'll agree that from some perspectives the new behavior of None is a
>> wart but I think that in the end I agree with people who say that
>> preventing None from being sorted except intentionally will
In article <[EMAIL PROTECTED]>,
Duncan Grisby <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, Aahz <[EMAIL PROTECTED]> wrote:
>>In article <[EMAIL PROTECTED]>,
>>Duncan Grisby <[EMAIL PROTECTED]> wrote:
>>>
>>>For my application, Python 3's comparison behaviour is a backwards
>>>step.
> Sorry for the delay in replying.
Thanks, and I'm in turn sorry myself, too. Here is my experiment:
I only looked at the first test case, where a bigfile.txt has
occasionally None lines. To run this test, I created a file with
33079296 and 704512 lines, by repeatedly cat'ing /etc/passwd.
I the
In article <[EMAIL PROTECTED]>, Aahz <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Duncan Grisby <[EMAIL PROTECTED]> wrote:
[...]
>>That's exactly my point. Currently, the application just builds a list
>>of values retrieved from the database and asks Python to sort it. No
>>key o
2008/11/24 Aahz <[EMAIL PROTECTED]>:
> (I'll agree that from some perspectives the new behavior of None is a
> wart but I think that in the end I agree with people who say that
> preventing None from being sorted except intentionally will trap more
> bugs earlier.)
So will Python be introducing s
In article <[EMAIL PROTECTED]>,
Duncan Grisby <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Terry Reedy <[EMAIL PROTECTED]> wrote:
>>
>>Replace the sublists with a coded string, such as '\0'+line.
>
>Again, this is just an example. As I say, in the real application, the
>data has c
In article <[EMAIL PROTECTED]>,
Terry Reedy <[EMAIL PROTECTED]> wrote:
[...]
>> l = []
>> for line in open("bigfile.txt"):
>> x = random.randint(0,100)
>> if x < 4: l.append(None)
>> else: l.append(line)
>
>So use '' or '\0' instead of None for null lines. Or replace None for
>the s
Duncan Grisby wrote:
Sorry for the delay in replying. Yes, that's not far off. Most of the
time the lists contain strings, though. A better approximation might
be to read lines from a file and randomly replace them with Nones:
l = []
for line in open("bigfile.txt"):
x = random.randint(0,10
In article <[EMAIL PROTECTED]>,
Martin v. Löwis <[EMAIL PROTECTED]> wrote:
>> The sorting is in a performance-critical part of the system, so the
>> overhead of evaluating a key function is not insignificant.
>
>Can you easily produce an example? It doesn't have to be real data,
>but should have t
Terry Reedy wrote:
M.-A. Lemburg wrote:
I think the special case for None should be readded to Python 3.0.
Quick summary of thread that MAL started on Python-3000-dev list:
Once upon a time, 0 < None was true.
When rich comparisons were added, None < 0 (and *most* other things)
become tru
> The sorting is in a performance-critical part of the system, so the
> overhead of evaluating a key function is not insignificant.
Can you easily produce an example? It doesn't have to be real data,
but should have the structure (typewise) of the real data. I would
like to perform some measuremen
M.-A. Lemburg wrote:
I think the special case for None should be readded to Python 3.0.
Quick summary of thread that MAL started on Python-3000-dev list:
Once upon a time, 0 < None was true.
When rich comparisons were added, None < 0 (and *most* other things)
become true as an intentionall
Duncan Grisby wrote:
Yes, very hard.
There is a difference between 'very hard' (to get 'right') and 'to slow'
(for a particular application). I accept the latter.
There are only ever simple types in the lists --
strings, integers, Nones, very occasionally floats, and lists of those
things
M.-A. Lemburg wrote:
On 2008-11-11 02:10, Steven D'Aprano wrote:
On Mon, 10 Nov 2008 12:51:51 +, Duncan Grisby wrote:
I have an object database written in Python. It, like Python, is
dynamically typed. It heavily relies on being able to sort lists where
some of the members are None. To som
On Nov 11, 8:02 am, "M.-A. Lemburg" <[EMAIL PROTECTED]> wrote:
> On 2008-11-11 02:10, Steven D'Aprano wrote:
>
> > On Mon, 10 Nov 2008 12:51:51 +, Duncan Grisby wrote:
>
> >> I have an object database written in Python. It, like Python, is
> >> dynamically typed. It heavily relies on being able
On 2008-11-11 02:10, Steven D'Aprano wrote:
> On Mon, 10 Nov 2008 12:51:51 +, Duncan Grisby wrote:
>
>> I have an object database written in Python. It, like Python, is
>> dynamically typed. It heavily relies on being able to sort lists where
>> some of the members are None. To some extent, it
In article <[EMAIL PROTECTED]>,
Terry Reedy <[EMAIL PROTECTED]> wrote:
>> I have an object database written in Python. It, like Python, is
>> dynamically typed. It heavily relies on being able to sort lists where
>> some of the members are None. To some extent, it also sorts lists of
>> other mix
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>On Sat, 08 Nov 2008 22:53:14 -0800, Kay Schluehr wrote:
>
>>> How often do you care about equality ignoring order for lists
>>> containing arbitrary, heterogeneous types?
>>
>> A few times. Why do you care, Steven?
>
>I'm a very caring kind of guy.
Tha
On Nov 10, 9:31 pm, Rhamphoryncus <[EMAIL PROTECTED]> wrote:
> On Nov 10, 6:25 pm, Steven D'Aprano
>
>
>
> <[EMAIL PROTECTED]> wrote:
> > On Mon, 10 Nov 2008 11:43:59 -0800, Rhamphoryncus wrote:
> > > You might as well comment out the sort and call it good. That's what
> > > you really had in 2.x.
On Nov 10, 6:25 pm, Steven D'Aprano
<[EMAIL PROTECTED]> wrote:
> On Mon, 10 Nov 2008 11:43:59 -0800, Rhamphoryncus wrote:
> > You might as well comment out the sort and call it good. That's what
> > you really had in 2.x. It was close enough most of the time to *look*
> > right, yet in truth it s
On Mon, 10 Nov 2008 11:43:59 -0800, Rhamphoryncus wrote:
> You might as well comment out the sort and call it good. That's what
> you really had in 2.x. It was close enough most of the time to *look*
> right, yet in truth it silently failed. 3.0 makes it an explicit
> failure.
I don't doubt th
On Mon, 10 Nov 2008 12:51:51 +, Duncan Grisby wrote:
> I have an object database written in Python. It, like Python, is
> dynamically typed. It heavily relies on being able to sort lists where
> some of the members are None. To some extent, it also sorts lists of
> other mixed types. It will b
[EMAIL PROTECTED] wrote:
> On Nov 10, 1:21 pm, Steve Holden <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] wrote:
>>> On Nov 10, 8:57 am, Steve Holden <[EMAIL PROTECTED]> wrote:
Robin Becker wrote:
>>> ...snip...
> In old style python there was a sort of standard behaviour whereby None
>>
On Nov 10, 12:39 pm, George Sakkis <[EMAIL PROTECTED]> wrote:
George Sakkis wrote:
> On Nov 10, 2:21 pm, [EMAIL PROTECTED] wrote:
>
>> So you could say that 3.0 is forcing us to acknowledge database
>>
>> > reality ;-)
>>
>> (Again) huh?
>> Reality in databases is that NULL *is* comparable.
>> "NUL
On Nov 10, 1:21 pm, Steve Holden <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > On Nov 10, 8:57 am, Steve Holden <[EMAIL PROTECTED]> wrote:
> >> Robin Becker wrote:
> > ...snip...
> >>> In old style python there was a sort of standard behaviour whereby None
> >>> was comparable with most
On Nov 8, 10:20 am, walterbyrd <[EMAIL PROTECTED]> wrote:
> I have read that in Python 3.0, the following will raise an exception:
>
> >>> [2, 1, 'A'].sort()
>
> Will that raise an exception? And, if so, why are they doing this? How
> is this helpful? Is this new "enhancement" Pythonic?
I realize
[EMAIL PROTECTED] wrote:
> On Nov 10, 8:57 am, Steve Holden <[EMAIL PROTECTED]> wrote:
>> Robin Becker wrote:
> ...snip...
>>> In old style python there was a sort of standard behaviour whereby None
>>> was comparable with most of the other primitive types. That at least
>>> allowed us to performs
On Nov 10, 8:16 am, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Duncan Grisby wrote:
> > In article <[EMAIL PROTECTED]>,
> > Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> >> Have you written any Python code where you really wanted the old,
> >> unpredictable behavior?
>
> > I have an object database wr
1 - 100 of 322 matches
Mail list logo
