ast majority of "newbie missing __init__.py"
problems within google occur because people are missing __init__.py at
the root of package import tree. This change would not not solve that
problem.
It wouldn't surprise me if this change would int
On Wed, 2006-04-05 at 12:13 -0700, Brett Cannon wrote:
> On 4/5/06, Donovan Baarda <[EMAIL PROTECTED]> wrote:
> > G'day,
> >
> > Just noticed on Debian (testing), Ubuntu (warty?), and RedHat (old)
> > based systems Python's time.strptime() seems to ignore
extensions. There has also been
a bug against strptime() Locale switching not working because of caching
Locale formatting info from the strftime() analysis, but I can't seem to
get non-C Locale's working at all...
--
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org
through a
print_debug() method that acquires and releases a debug_lock
threading.Lock. This is simpler as it avoids the separate thread, and
ensures that threads "pause" until their debugging output is done.
--
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/
___
info/python-dev
> > Unsubscribe:
> > http://mail.python.org/mailman/options/python-dev/guido%40python.org
> >
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> ___
> Python-Dev mailing list
> Python-De
dify the data in any way, it just changes its
type/class to be the other type, and assumes that the data is a valid
instance of the other type; eg int32 -> bytes[4]. Minor data munging
under the hood to cleanly switch the type/class is acceptable (ie adding
array length info
there was a time.mkgmtime(), but it would need to be
implemented in C.
--
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-d
On Thu, 2006-02-09 at 13:12 +0100, Fredrik Lundh wrote:
> Donovan Baarda wrote:
>
> >> Here I think you meant that medusa didn't handle computation in separate
> >> threads instead.
> >
> > No, I pretty much meant what I said :-)
> >
> > Me
On Wed, 2006-02-08 at 15:14 +0100, Valentino Volonghi aka Dialtone
wrote:
> On Wed, Feb 08, 2006 at 01:23:26PM +0000, Donovan Baarda wrote:
> > I believe that Twisted does pretty much this with it's "deferred" stuff.
> > It shoves slow stuff off for processing in
ibute connections to
them. This way it wasn't too bad if an async loop stalled, because the
other loops in other threads could continue to process stuff.
If ZEO is still using this approach I think switching to a twisted style
approach would be a good idea. However, I suspe
On Mon, 2006-02-06 at 15:36 +0100, Ronald Oussoren wrote:
> On Monday, February 06, 2006, at 03:12PM, Donovan Baarda <[EMAIL PROTECTED]>
> wrote:
>
> >On Fri, 2006-02-03 at 20:02 +0100, "Martin v. Löwis" wrote:
> >> Donovan Baarda wrote:
> >>
On Fri, 2006-02-03 at 20:02 +0100, "Martin v. Löwis" wrote:
> Donovan Baarda wrote:
> > Before set() the standard way to do them was to use dicts with None
> > Values... to me the "{1,2,3}" syntax would have been a logical extension
> > of the "a set i
On Fri, 2006-02-03 at 11:56 -0800, Josiah Carlson wrote:
> Donovan Baarda <[EMAIL PROTECTED]> wrote:
[...]
> > Nuff was a fairy... though I guess it depends on where you draw the
> > line; should [1,2,3] be list(1,2,3)?
>
> Who is "Nuff"?
fairynuff... :-)
&
builtin.
> I personally object to making syntax for sets for the same reasons I
> object to making arrays, heapqs, Queues, deques, or any of the other
> data structure-defining modules in the standard library into syntax.
Nuff was a fairy... though I guess it depends on where you draw
On Fri, 2006-02-03 at 12:04 +, Donovan Baarda wrote:
> On Wed, 2006-02-01 at 13:55 -0500, Greg Wilson wrote:
[...]
> Personally I'd like this. currently the "set(...)" syntax makes sets
> feel tacked on compared to tuples, lists, dicts, and strings which have
> n
e, {1:'a',2:'b'}
is a dict, f{1:'a',2:'b'} is a "frozen dict" which can be used as a key
in other dicts... etc.
--
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/
___
Python-De
mal, hexadecimal,
octal, and binary cover 99.9% of cases. The 0.1% of other cases are very
special, and can use int("LITERAL",base=RADIX).
For me, binary is far more useful than octal, so I'd be happy to let
octal languish as legacy support, but
essential, but I don't mind not having "deleted
in"... it encourages developers stuck in those time-warps to avoid
features that get deleted in the future :-)
--
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/
ho would ever use it?", I would :-)
Note that this does not support and is independent of supporting
arbitrary bases. I don't think we need to support arbitrary bases, but
if we did I would vote for ".precision" to mean ".base" for "%d"... ie;
"%3.3d&qu
ot; for bytes and "b" for bits... though I can't imagine
why byte would need it's own conversion type.
I'm not entirely sure everyone is on the same page for "%b" here... it
would only be a shorthand for "binary" in the same way that &qu
d base 16 float notation for fixed-point numbers.
I personally think %b would be adding enough. The other suggestions are
just me being silly :-)
--
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/
___
Python-Dev mailin
6 (x, X). Why not just add a string format code for unsigned
> > binary? The obvious choice is probably "b".
> >
> > For example:
> >
> > >>> '%08b' % (12)
> > '1100'
> > >>&g
the autotools autogen'ed files, generated datafiles, etc.
This way your source distributions don't have any bootstrap problems,
but you also don't have any auto-generated files in CVS/SVN and the
problems they create. It does however mean that a fresh CVS/SVN checkout
does have a
on't do this enough to really know if that's worth it.
If the markup is changed to something more widely known and/or simple,
more people might participate in the "generate patch" workflow rather
than the "submit bug" workflow, and maybe that will make things easier
f
p
by creating a new container and del'ing the old one. If the
implementation is changed to use this heuristic, there is no simple way
to avoid the re-allocs for this use-case... (don't empty, but fill with
None... ugh!).
My gut feeling is this heuristic will cause more pain than it would
it wouldn't be a good idea to centralise all filesystem
operations into the os module, including open() or file(). Perhaps the
builtin open() and file() could call os.file()... or P3K could remove
the builtins... I dunno... it just felt ugly at the tim
bigger than that, assume it's half way through growing". which is
what Python currently does.
Without some sort of fancy overkill size hinting or history tracking,
that's probably as good a heuristic as you can get.
--
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.a
es-to-match
re's.
I suspect it would be do-able... I suggest you put together a patch and
submit it on SF...
--
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/
___
Python-Dev mailing list
Python-Dev@python.org
http:/
()" and "netlocunparse()" that is for parsing and unparsing
"user:[EMAIL PROTECTED]:port" netloc's.
Feel free to use/add/ignore it...
http://minkirri.apana.org.au/~abo/projects/osVFS/netlocparse.py
--
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org
s and possible race conditions of threads.
It has the problem that a single co-routine can monopolise execution,
hence the other name "co-operative multi-tasking", where co-operation is
the requirement for it to work.
At least... that's the way I understood it... I could be to
port for using a
variety of different event-loops, including Tkinter and wxWidgets, as
well as it's own.
It has been heavily re-factored many times, so if you want to see the
current Python "state of the art" way of doing this, I'd be having a
look at what they are doing.
--
Donov
is actually broken.
I don't know how many bits of other people's code I've had to fix that
worked for years until it was run on hardware fast enough to trigger
that nasty race condition :-)
--
Donovan Baarda <[EMAIL PROTECTED]>
___
ays choose the async
solution. Not because async is inherently better than threading, but
because the programmer who bothered to grock async is more likely to get
it right.
--
Donovan Baarda <[EMAIL PROTECTED]>
___
Python-Dev mailing l
reading based message passing
implementations could instead be spent on inter-process messaging.
--
Donovan Baarda <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubs
d memory will force
serious multi-processing to use IPC channels. If you want serious MP,
use processes, not threads.
I see anti-GIL threads again and again. Get over it... the GIL rocks for
threads :-)
--
Donovan Baarda <[EMAIL PROTECTED]>
_
dmittedly a long time ago...
--
--------
Donovan Baardahttp://minkirri.apana.org.au/~abo/
___
Python-Dev mailing l
and opinion). If you had been ruminating
> over this previously, great, but that did not seem clear to me in your
> original reply to Terry Reedy.
bare in mind they are talking about Python 3.0... I think :-)
--
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/
"data" objects might hang
around just because some small fragment of it is still referenced by a
string. Surely a simple huristic or two like "if len(string) <
len(data)/8: copy data; else: reference data" would go a long way
towards avoiding that.
In my limited playing ar
any upstream
CVS and SVN repositorys, using a local PRCS for my own branches. I'm
considering switching to a distributed RCS for my own branches because
it would make it easier for others to share them.
I think this probably is the best solution; it gives a reliable(?)
centralised RCS fo
On Mon, 2005-08-08 at 17:51, Trent Mick wrote:
[...]
> [Donovan Baarda wrote]
> > On Mon, 2005-08-08 at 15:49, Trent Mick wrote:
[...]
> You want to do checkins of code in a consisten state. Some large changes
> take a couple of days to write. During which one may have to do a
lop/test them independantly. The branch can then be reviewed and
merged when it is complete.
--
Donovan Baarda <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Martin v. Löwis wrote:
> Donovan Baarda wrote:
>
>>Yeah. IMHO the sadest thing about SVN is it doesn't do branch/merge
>>properly. All the other cool stuff like renames etc is kinda undone by
>>that. For a definition of properly, see;
>>
>>http://prcs.s
On Tue, 2005-08-02 at 11:59, Gabriel Becedillas wrote:
> Donovan Baarda wrote:
[...]
> > Wow... you guys sure did it the hard way. If you had done it at the
> > Python level, you would have had a much easier time of both implementing
> > and updating it.
[...]
> Hi, than
hat this is not one of those
bits of software.
IMHO you need maturity for revision control software... you are relying
on it for history. The only open source options worth considering for
Python are CVS and SVN, and even SVN is questionable (see bdb backend
issues).
--
Donovan Baarda <[EMAIL PROTECT
at tricks Python into using a virtual file
system;
http://minkirri.apana.org.au/~abo/projects/osVFS
--
Donovan Baarda <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
h the pain of migrating. For new projects
sure, SVN is a better choice than CVS.
--
Donovan Baarda <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
stat() method (there is lots of other goodies in a stat).
--
Donovan Baarda <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Josiah Carlson wrote:
> Donovan Baarda <[EMAIL PROTECTED]> wrote:
>
>>Nick Coghlan wrote:
>>
>>>Donovan Baarda wrote:
[...]
>>But isn't a function just a deferred expression with a name :-)
>
>
> A function in Python is actually a deferred s
Nick Coghlan wrote:
> Donovan Baarda wrote:
>
>>As I see it, a lambda is an anonymous function. An anonymous function is
>>a function without a name.
>
>
> And here we see why I'm such a fan of the term 'deferred expression'
> instead of '
r ";" to resolve ambiguity.
This must have been proposed already and shot down in flames... sorry
for re-visiting old stuff and contributing noise.
--
Donovan Baarda
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.or
tuples of corresponding files. It optionally will
not decend directories in either tree that do not have a corresponding
directory in the other tree. See;
http://minkirri.apana.org.au/~abo/projects/utils/
--
Donovan Baarda <[EMAIL PROTECTED]>
___
On Mon, 2005-04-25 at 21:21 -0400, Brian Beck wrote:
> Donovan Baarda wrote:
> > Agreed. I don't find any switch syntaxes better than if/elif/else. Speed
> > benefits belong in implementation optimisations, not new bad syntax.
>
> I posted this 'switch' rec
if/else. Speed
benefits belong in implementation optimisations, not new bad syntax.
--
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
On Mon, 2005-03-21 at 23:31 +1100, Donovan Baarda wrote:
> On Mon, 2005-03-21 at 11:42 +0100, Peter Astrand wrote:
> > On Mon, 21 Mar 2005, Donovan Baarda wrote:
> >
> > > > > The only ways to ensure that a select process does not block like
> > > > &g
On Tue, 2005-03-22 at 12:49 +1200, Greg Ewing wrote:
> Donovan Baarda wrote:
>
> > Consider the following. This is pretty much the only way you can use
> > popen2 reliably without knowing specific behaviours of the executed
> > command;
> >
> > ...
>
On Mon, 2005-03-21 at 11:42 +0100, Peter Astrand wrote:
> On Mon, 21 Mar 2005, Donovan Baarda wrote:
>
> > > > The only ways to ensure that a select process does not block like this,
> > > > without using non-blocking mode, are;
>
> > > 3) Use os.read
G'day,
From: "Greg Ward" <[EMAIL PROTECTED]>
> On 18 March 2005, Donovan Baarda said:
[...]
> > Currently the built in file type does not support non-blocking mode very
> > well. Setting a file into non-blocking mode and reading or writing to
it
> > can
G'day,
From: "Peter Astrand" <[EMAIL PROTECTED]>
> On Mon, 21 Mar 2005, Donovan Baarda wrote:
[...]
> This is no "trap". When select() indicates that you can write or read, it
> means that you can write or read at least one byte. The .read() and
> .write
On Mon, 2005-03-21 at 17:32 +1200, Greg Ewing wrote:
> > On 18 March 2005, Donovan Baarda said:
>
> >>Many Python library methods and classes like select.select(), os.popen2(),
> >>and subprocess.Popen() return and/or operate on builtin file objects.
> >>Howev
e behaviour of fread/fwrite is indeed indeterminate under
non-blocking mode, then yes, file objects in non-blocking mode would
have to use read/write instead of fread/fwrite. However, I don't think
this is required.
I know this PEP is kinda insignificant and minor. It doesn't save much,
but
fuss over it any more I'll never get it
out...
--
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/
PEP: XXX
Title: Make builtin file objects support non-blocking mode
Version: $Revision: 1.0 $
Last-Modified: $Date: 2005/03/18 11:34:00 $
Author: Donovan Baarda &
G'day again,
From: "Michael Hudson" <[EMAIL PROTECTED]>
> "Donovan Baarda" <[EMAIL PROTECTED]> writes:
>
> >
> > Just my 2c;
> >
> > I don't mind new features in minor releases, provided they meet the
> > following t
sion
required for their application.
Any change that breaks rule 1) must be delayed until a major release. Any
change that breaks rule 2) is a documentation bug that needs fixing.
Donovan Baardahttp://minkirri.apana.org
From: "Martin v. Löwis" <[EMAIL PROTECTED]>
> Donovan Baarda wrote:
> > This patch keeps the current md5c.c, md5module.c files and adds the
> > following; _hashopenssl.c, hashes.py, md5.py, sha.py.
> [...]
> > If all we wanted to do was fix the md5 module
&g
omain".
Apparently lawyers have decided that you can't give code away. Intellectual
charity is illegal :-)
Donovan Baardahttp://minkirri.apana.org.au/~abo/
---
new = md5
Despite all these nit-picks, it looks pretty good. It is orders of
magnitude better than any of the other non-existent solutions, including
the one I didn't code :-)
--
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/
_
G'day,
On Sat, 2005-02-12 at 13:04 -0800, Gregory P. Smith wrote:
> On Sat, Feb 12, 2005 at 08:37:21AM -0500, A.M. Kuchling wrote:
> > On Sat, Feb 12, 2005 at 01:54:27PM +1100, Donovan Baarda wrote:
> > > Are there any potential problems with making the md5sum mod
Is it using the openssl sha interface, or the higher level
EVP interface?
The reason I ask is it would be pretty trivial to modify md5module.c to
use the openssl API for any digest, and would be less risk than
fresh-coding one.
--
Donovan Baarda <[EM
thon is already dependant on openssl, it makes sense to change
md5sum to use it. I have a feeling that openssl internally uses md5, so this
way we wont link against two different md5sum implementations.
-
G'day,
From: "Bob Ippolito" <[EMAIL PROTECTED]>
> On Feb 11, 2005, at 6:11 PM, Donovan Baarda wrote:
[...]
> > Given that Python is already dependant on openssl, it makes sense to
> > change
> > md5sum to use it. I have a feeling that openssl internally
On Fri, 2005-02-11 at 17:15 +1100, Donovan Baarda wrote:
[...]
> I think it would be cleaner and simpler to modify the existing
> md5module.c to use the openssl md5 layer API (this is just a
> search/replace to change the function names). The bigger problem is
> deciding what/ho
On Thu, 2005-02-10 at 23:13 -0500, Bob Ippolito wrote:
> On Feb 10, 2005, at 9:50 PM, Donovan Baarda wrote:
>
> > On Thu, 2005-02-10 at 21:30 -0500, Bob Ippolito wrote:
[...]
> > Only problem with this, is pyopenssl doesn't yet include any mdX or sha
> > modules.
&g
On Thu, 2005-02-10 at 21:30 -0500, Bob Ippolito wrote:
> On Feb 10, 2005, at 9:15 PM, Donovan Baarda wrote:
>
> > On Tue, 2005-02-08 at 11:52 -0800, Gregory P. Smith wrote:
[...]
> One possible alternative would be to bring in something like PyOpenSSL
> <http://pyopenssl.
igrating to the openssl API. If people hassle me, I could
probably do the openssl API migration for Python, but I'm not sure what
the best approach would be to including the source in Python sources.
FWIW, I also have an md4sum module and md4c.c implement
On Tue, 2005-02-01 at 10:30 +1100, Donovan Baarda wrote:
> On Mon, 2005-01-31 at 15:16 -0500, Nathan Binkert wrote:
> > > Wouldn't it be nicer to have a facility that let you send messages
> > > between processes and manage concurrency properly instead? You'll nee
(or just outright rejected)
different ways of doing it, to varying degrees of success. IMHO, the
fact that QNX doesn't distribute threads speaks volumes.
--
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/
___
Python-Dev maili
s be hard to
distribute efficiently over multiple CPU's. If you want to run on
multiple processors, use processes, not threads.
--
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/
___
Python-Dev mailing list
Python-De
On Wed, 2005-01-26 at 01:53 +1100, Anthony Baxter wrote:
> On Wednesday 26 January 2005 01:01, Donovan Baarda wrote:
> > In this case it turns out to be "don't do exec() in a thread, because what
> > you exec can have all it's signals masked". That turns out
G'day,
From: "Anthony Baxter" <[EMAIL PROTECTED]>
> On Thursday 20 January 2005 12:43, Donovan Baarda wrote:
> > On Wed, 2005-01-19 at 13:37 +, Michael Hudson wrote:
> > > The main oddness about python threads (before 2.3) is that they run
> > >
On Thu, 2005-01-20 at 14:12 +, Michael Hudson wrote:
> Donovan Baarda <[EMAIL PROTECTED]> writes:
>
> > On Wed, 2005-01-19 at 13:37 +, Michael Hudson wrote:
> >> Donovan Baarda <[EMAIL PROTECTED]> writes:
[...]
> >> The main oddness about py
On Wed, 2005-01-19 at 13:37 +, Michael Hudson wrote:
> Donovan Baarda <[EMAIL PROTECTED]> writes:
[...]
> You've left out a very important piece of information: which version
> of Python you are using. I'm guessing 2.3.4. Can you try 2.4?
Debian Python2.3 (2.3.4
objects really could use better non-blocking
support... I've got a half-drafted PEP for it... anyone interested in
it?
--
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/
test-fop.py
Description: application/python
__
82 matches
Mail list logo
