Paul Moore wrote:
2009/1/30 Walter Dörwald :
Paul Moore wrote:
[...]
In all honesty, I think pkgutil.simplegeneric should be documented,
exposed, and moved to a library of its own[1].
http://pypi.python.org/pypi/simplegeneric
Thanks, I was aware of that.
I wasn't aware of the fact that si
Ludvig Ericson wrote:
> Well, I was trying to be funny and was under the impression that Python
> 3.0 had Unicode identifiers, but apparently it doesn't. (I used …, not ...)
It does, but they may not contain characters of the category
"Punctuation, other":
>>> import unicodedata
>>> unicodedata.c
As I've mentioned, I've been re-examining from ground up the whole
state of affairs in writing a debugger.
One of the challenges of a debugger or any source-code analysis tool
is verifying that the source-code that the tool is reporting on
corresponds to the compiled object under execution. (For d
The array.array type is an excellent type for storing a large amount of
"native" elements, such as integers, chars, doubles, etc., without
involving the heavy machinery of numpy. It's both blazingly fast and
reasonably efficient with memory. The one thing missing from the array
module is the
Paul Moore wrote:
> 2009/2/2 Nick Coghlan :
>> A trio of patches that:
>> 1. promoted simplegeneric from pkgutil to functools (with appropriate
>> documentation and tests)
>> 2. changed pkgutil to use functools.simplegeneric instead of its current
>> internal version
>> 3. updated pprint to be a g
[Hrvoje Niksic]
The one thing missing from the array
module is the ability to directly access array values from C.
Please put a feature request on the bug tracker.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/
On Mon, Feb 2, 2009 at 00:52, Rocky Bernstein wrote:
> As I've mentioned, I've been re-examining from ground up the whole
> state of affairs in writing a debugger.
>
> One of the challenges of a debugger or any source-code analysis tool
> is verifying that the source-code that the tool is reportin
Walter Dörwald wrote:
> Paul Moore wrote:
>> 2009/1/30 Walter Dörwald :
>>> Paul Moore wrote:
>>>
[...]
In all honesty, I think pkgutil.simplegeneric should be documented,
exposed, and moved to a library of its own[1].
>>> http://pypi.python.org/pypi/simplegeneric
>>
>> Thanks, I was
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 31, 2009, at 2:43 PM, Martin v. Löwis wrote:
How about Friday February 13?
Fine with me (although next Friday (Feb 6) would work slightly better)
Feb 6 won't work for me. Would the 20th be better for you Martin?
Barry
-BEGIN PGP S
2009/2/2 Nick Coghlan :
> Paul Moore wrote:
>> 2009/2/2 Nick Coghlan :
>>> A trio of patches that:
>>> 1. promoted simplegeneric from pkgutil to functools (with appropriate
>>> documentation and tests)
>>> 2. changed pkgutil to use functools.simplegeneric instead of its current
>>> internal versio
On 29 Jan 2009, at 21:54, Nick Coghlan wrote:
For the "reiterable" cases like dictionary views (where the object is
not consumed), an appropriate __str__ or __repr__ should be written).
Indeed, instead of having a __pprint__ why not just allow a __repr__
to reformat its output?
dict havin
Tres Seaver wrote:
> Nick Coghlan wrote:
>> (and don't worry too much about 3 - it will give me an opportunity to
>> road test the functools patch by using it to refactor pprint and check
>> the performance implications)
>
> /me wonders about the performance-criticality of anything using
> 'pprint
On 2009-02-02 14:50, Nick Coghlan wrote:
Really drastic performance degradations would be on the radar as well -
slowing pprint() down by 10% is unlikely to bother anyone, but slowing
it down by 100% would be a bad thing (not that I think such a
degradation is likely, I'm just trying to give an i
On Mon, Feb 2, 2009 at 11:38 AM, Nick Coghlan wrote:
> That's what the -3 command line switch is for - it sets a boolean flag
> that C code can check to see if it should emit warnings for things that
> are going to break in Python 3.x.
Understood. My worry was that we'd get a lot of false positi
>> Fine with me (although next Friday (Feb 6) would work slightly better)
>
> Feb 6 won't work for me. Would the 20th be better for you Martin?
No, they are both busy days - Feb 13 is then slightly better than Feb
20. I have about an hour in the morning (around 8:00 UTC), and then
after 15:00 U
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 2, 2009, at 4:48 PM, Martin v. Löwis wrote:
Fine with me (although next Friday (Feb 6) would work slightly
better)
Feb 6 won't work for me. Would the 20th be better for you Martin?
No, they are both busy days - Feb 13 is then slightly
> I'm wondering if Mark should add the exception he recently removed back
> in as a Deprecation Warning when tp_compare is defined, but
> tp_richcompare is not. Such a warning should also be present when
> running with -3 in 2.7 (assuming it isn't already there).
>
> Otherwise we're going to get m
> Understood. My worry was that we'd get a lot of false positives---
> i.e., warnings about pieces of Python 2.7 that don't need to change.
> But I guess that's okay.
I don't personally use the -3 flag, but I would expect that these
would indeed be annoying. We could arrange to exempt them, by
in
> Don't you rememeber the PC:s in the late 1980th? It was based on
> Intel's 80286-processor, and Microsoft's C compiler supported
> three or four different memory models, called things like "TINY",
> "SMALL", "LARGE", and "HUGE". Most of these memory models had
> different sized data and function
Terry Reedy wrote:
> Campbell Barton wrote:
> In 3.0, the build-in cmp() should have been removed and will be for
> 3.0.1. Do not use it. I believe the tp_compare slot should not be used
> either. It will become reserved. It will not be removed only because
> that would change the binary layout
On 2009-02-01 19:44, Reto Schüttel wrote:
> Hi
>
> While helping Brandon Rhodes to port PyEphem[1] to Python 3 we struggled
> over a
> strange locale-related problem on OS X. PyEphem is a library which can do
> astronomical computations like tracking the position of stars, planets and
> earth sate
Sorry for being a pest here...
still, I'd be grateful if someone could please try and take look at the
patches I've posted on bugs.python.org for smtplib, imaplib and poplib,
since I think they could be useful for a future 2.x release of the
standard library, and I've verified they port almost
Sorry!
Somehow my mailclient managed to mess up my message, here
another copy of it, hopefully in better conditions than last
time.
Aahz: Good idea, I've created a bug report. Bug ID 5125
Hi
While helping Brandon Rhodes to port PyEphem[1] to Python 3 we
struggled over a strange locale-related
Sorry for being a pest here...
and for forgetting to put pointers to the issues in the previous
attempt... the issues on bugs.python.org are:
http://bugs.python.org/issue4470 - smtplib SMTP_SSL not working
http://bugs.python.org/issue4471 - IMAP4 missing support for starttls
http:/
Mark Dickinson wrote:
> On Mon, Feb 2, 2009 at 10:36 AM, Nick Coghlan wrote:
>> Such a warning should also be present when
>> running with -3 in 2.7 (assuming it isn't already there).
>
> I'm not sure how/whether that would work, given that there are
> probably still plenty of 2.7 modules in the
On Mon, Feb 2, 2009 at 10:36 AM, Nick Coghlan wrote:
> I'm wondering if Mark should add the exception he recently removed back
> in as a Deprecation Warning when tp_compare is defined, but
> tp_richcompare is not.
This sounds reasonable to me. A third-party module that implements
tp_compare but
I'm happy to announce that the Python Software Foundation has
allocated funds to help people attend PyCon 2009!
If you would like to come to PyCon but can't afford it, the PSF may be
able to help you pay for registration, lodging/hotel costs and
transportation (flight etc.). Please see http
On Mon, Feb 2, 2009 at 10:48 AM, wrote:
> Brett Cannon writes:
> > On Mon, Feb 2, 2009 at 00:52, Rocky Bernstein wrote:
> > > As I've mentioned, I've been re-examining from ground up the whole
> > > state of affairs in writing a debugger.
> > >
> > > One of the challenges of a debugger or a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nick Coghlan wrote:
> Paul Moore wrote:
>> 2009/2/2 Nick Coghlan :
>>> A trio of patches that:
>>> 1. promoted simplegeneric from pkgutil to functools (with appropriate
>>> documentation and tests)
>>> 2. changed pkgutil to use functools.simplegeneric
2009/2/2 Nick Coghlan :
> A trio of patches that:
> 1. promoted simplegeneric from pkgutil to functools (with appropriate
> documentation and tests)
> 2. changed pkgutil to use functools.simplegeneric instead of its current
> internal version
> 3. updated pprint to be a generic function (and hence
Brett Cannon writes:
> On Mon, Feb 2, 2009 at 00:52, Rocky Bernstein wrote:
> > As I've mentioned, I've been re-examining from ground up the whole
> > state of affairs in writing a debugger.
> >
> > One of the challenges of a debugger or any source-code analysis tool
> > is verifying that th
ro...@gnu.org wrote:
But the
expectation is that the programmer thinks it matches what is currently
on A that the programmer is debuggging. Can I tell for certain?
You can always find out by compiling the source and
comparing the resulting bytecode with what is currently
on A. Not that this is
Greetings Pythonistas,
ConfigParser as you most certainly know is a .ini parser included in
the Python standard library. It's documentation mentions a
DuplicateSectionError but I was puzzled after hunting a bug in our
application that this error was not raised when parsing a file with
duplicat
33 matches
Mail list logo
