On Tue, 2008-10-07 at 11:30 +0200, Victor Stinner wrote:
> > - I'd think "find . -type f -print0 | xargs -0 python -c 'pass'"
> > ought to work (with files with "bad" bytes being returned by find),
>
> First, fix your home directory :-) There are good tools (convmv?) to fix
> invalid filenames.
On Tue, 2008-09-30 at 07:26 -0700, Guido van Rossum wrote:
> > I am not convinced that a word processor can just ignore files with
> > (what it thinks are) undecodable file names. In countries with a
> > history of incompatible national encodings, such file names crop up very
> > often, sometimes
On Tue, 2008-09-30 at 19:45 +1000, Nick Coghlan wrote:
> To my mind, there are two kinds of app in the world when it comes to
> file paths:
> 1) "Normal" apps (e.g. a word processor), that are only interested in
> files with sane, well-formed file names that can be properly decoded to
> Unicode wit
On Wed, 2008-08-13 at 22:20 +1000, Anthony Baxter wrote:
> Last time I looked at it, the C API wasn't nailed down yet. That's why
> I passed over it entirely for my tutorial. The only advice I was able
> to give was that if your extension is just a wrapper around existing C
> code, you might be bet
On Mon, 2008-06-16 at 22:27 +0200, M.-A. Lemburg wrote:
> On 2008-06-15 16:47, Georg Brandl wrote:
> > Thomas Lee schrieb:
> >> Georg Brandl wrote:
> >>> Remember that it must still be possible to write (in 2.6)
> >>>
> >>> True = 0
> >>> assert not True
> >>
> >> Ah of course. Looks like I should
On Fri, 2008-05-16 at 08:04 -0400, Tom Pinckney wrote:
> Here's one example, albeit from a few years ago
>
> http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/1625465
Thanks for the pointer. I'm not sure I fully understand Konrad Hinsen's
concerns, but maybe the problem is that Nump
On Thu, 2008-05-15 at 21:02 -0400, Tom Pinckney wrote:
> I found some other references where people were expressing concern
> over numpy releasing the GIL due to the fact that other C extensions
> could call numpy and unexpectedly have the GIL released on them (or
> something like that).
Cou
On Tue, 2008-04-29 at 15:34 +0200, Giovanni Bajo wrote:
> > As of 2.6, Greg's use case is addressed by the new 'delete' parameter on
> > tempfile.NamedTemporaryFile.
>
> Then I personally don't have any objection to the removal of os.mkstemp.
os.mkstemp is still useful when you *don't* need the
On Thu, 2008-04-10 at 09:23 +0800, Alvin Delagon wrote:
> I'm currently writing a simple python SCTP module in C. So far it
> works sending and receiving strings from it.
[...]
> I'm going to construct an SS7 packet in python using struct.pack().
> Here's the question, how am I going to pass the p
Are pickle files intended to be readable across different machine
architectures? The documentation states unequivocally that they are
compatible across Python versions, but compatibility across machine
architectures (wrt to differences in size and layout of primitive C
types) is not explicitly add
On Tue, 2007-10-02 at 11:30 +0100, Gustavo Carneiro wrote:
> even large memory objects, there is always explicit
> management.
> cStringIO's "close" method provides a precedent.
>
> I think close in real files is needed not so much because you want to
> free memory, but th
On Tue, 2007-10-02 at 10:50 +0100, Gustavo Carneiro wrote:
> Correct. And that reminds me of the limitation of the the Python GC:
> it doesn't take into account how much memory is being indirectly
> retained by a Python Object. Like in the example I already gave,
> gtk.gdk.Pixbuf can easily hold
On Thu, 2007-09-13 at 18:38 -0500, [EMAIL PROTECTED] wrote:
> Hrvoje> More precisely, Python will call the deallocator appropriate for
> Hrvoje> the object type. If that deallocator does nothing, the object
> Hrvoje> continues to live. Such objects could also start out with a
> Hrvoje
On Thu, 2007-09-13 at 13:15 +0200, "Martin v. Löwis" wrote:
> > To put it another way, would it actually matter if the reference
> > counts for such objects became hopelessly wrong due to non-atomic
> > adjustments?
>
> If they drop to zero (which may happen due to non-atomic adjustments),
> Pytho
On Fri, 2007-09-07 at 16:20 -0700, Bill Janssen wrote:
> > #define SSL_ALLOW_THREADS {if (_ssl_locks != NULL) { Py_BEGIN_ALLOW_THREADS
> > }}
> > #define SSL_DISALLOW_THREADS {if (_ssl_locks != NULL) {
> > Py_BEGIN_ALLOW_THREADS }}
>
> I'd forgotten how convoluted Py_BEGIN_ALLOW_THREADS and
> Py
On Fri, 2007-08-24 at 09:01 -0700, Neal Norwitz wrote:
> Right. I looked at this with Jeffrey Yasskin and agree that a lock is
> needed for f_fp. The fix is ugly because it's needed around all
> accesses to f_fp and there are a ton of them. Some are with the GIL
> held and others when it isn't.
On Thu, 2007-08-23 at 11:57 -0700, Neal Norwitz wrote:
> > "allow threads" section that runs with the GIL released, file_close
> > might acquire the GIL and be running in parallel to this code. If
> > file_close sets f_fp to NULL after the "if" condition evaluates, but
> > before the call to _port
On Wed, 2007-08-22 at 21:32 -0700, Neal Norwitz wrote:
> Py_BEGIN_ALLOW_THREADS
> errno = 0;
> - ret = _portable_fseek(f->f_fp, offset, whence);
> + if (f->f_fp != NULL)
> + ret = _portable_fseek(f->f_fp, offset, whence);
Doesn't this kind of code retain
On Wed, 2007-08-22 at 10:35 +0200, Hrvoje Nikšić wrote:
> I think we need a reliable mechanism to prevent file_close messing with
> f_fp while other operations are being performed. Since each FILE has an
> internal lock associated with it, flockfile could be used to lock out
> the s
On Tue, 2007-08-21 at 09:14 -0700, Neal Norwitz wrote:
> The patch is insufficient to prevent all types of crashes that occur
> when accessing a file from 2 threads (closing in one and doing
> whatever in another).
You are right. I wouldn't go so far to say the file object
thread-unsafe, but it c
On Mon, 2007-08-20 at 20:27 +0200, Maciej Fijalkowski wrote:
> import thread
>
> while 1:
> f = open("/tmp/dupa", "w")
> thread.start_new_thread(f.close, ())
> f.close()
file_close inadvertently allows fclose to be called twice on the same
stdio file. This patch should fix the proble
On Wed, 2007-06-20 at 19:26 +0200, "Martin v. Löwis" wrote:
> As Hrvoje says: try python-list (aka comp.lang.python). If you don't
> get an answer, you didn't phrase your question interestingly enough,
> or nobody knows the answer, or nobody has the time to tell you.
The thing with comp.lang.pytho
On Wed, 2007-06-20 at 22:12 +1000, Campbell Barton wrote:
> Hrvoje Nikšić wrote:
> > [ Note that this discussion, except maybe for the suggestion to add a
> > simpler way to call a method with keyword args, is off-topic to
> > python-dev. ]
>
> Is there a list for
[ Note that this discussion, except maybe for the suggestion to add a
simpler way to call a method with keyword args, is off-topic to
python-dev. ]
On Wed, 2007-06-20 at 20:17 +1000, Campbell Barton wrote:
> I dont think I can use PyObject_GetAttrString because the subtype would
> return a refere
On Wed, 2007-06-20 at 00:21 +1000, Campbell Barton wrote:
> I want to add my own call's before and after PyLists standard functions
> but have a proplem with functons that use keywords and have no API
> equivalent.
> For example, I cant use the API's PyList_Sort because that dosnt support
> keyword
On Wed, 2007-05-16 at 22:17 -0700, Talin wrote:
> Here's a simple method: Put up a free porn site [...]
Is it known that someone actually implemented this? It's a neat trick,
but as far as I know, it started as a thought experiment of what *could*
be done to fairly easily defeat the captchas, as
On Fri, 2007-05-11 at 13:06 -0700, Guido van Rossum wrote:
> > attribution_pattern = re.compile(ur'(---?(?!-)|\u2014) *(?=[^ \n])')
>
> But wouldn't it be just as handy to teach the re module about \u and
> \U, just as it already knows about \x (and \123 octals)?
And \n, \r, etc. Implementin
On Thu, 2007-03-22 at 13:38 -0700, Guido van Rossum wrote:
> Sounds good to me. In 3.0 we should probably not have os.popen*(), nor
> the popen2 module at all, and do everything via the subprocess module.
> I wonder if we should even get rid of os.system(); then there should
> be a subprocess.syste
On Wed, 2007-02-07 at 15:39 +0100, Hrvoje Nikšić wrote:
> The patch could look like this. If there is interest in this, I can
> produce a complete patch.
The complete patch is now available on SourceForge:
http://sourceforge.net/tracker/index.php?func=detail&aid=1658799&grou
On Mon, 2007-02-12 at 12:29 -0800, Josiah Carlson wrote:
> Hrvoje Nikšic <[EMAIL PROTECTED]> wrote:
> >
> > I propose modifying PyString_InternInPlace to better cope with string
> > subtype instances.
>
> Any particular reason why the following won't work for you?
[... snipped a simple intern imp
I propose modifying PyString_InternInPlace to better cope with string
subtype instances.
Current implementation of PyString_InternInPlace does nothing and
returns if passed an instance of a subtype of PyString_Type. This is a
problem for applications that need to support string subtypes, but also
31 matches
Mail list logo
