Hello, and thanks for the PEP,
I feel like the 3-lines declaration of a new sentinel would discourage a
bit its adoption compared to just "sentinel = object()"
From what I understand from the PEP, if new classes are defined inside
the closure of a factory function, some Python implementations w
Le 17/11/2013 12:27, Steven D'Aprano a écrit :
What I would like to know is if people *knowingly* add costly asserts
to performance-critical code, with the intent of disabling them at
runtime using -OO.
Yes, I have knowingly added costly asserts to code with the intend of
disabling them at runt
tting children module survive disconnected from
their parent) is more harmful than useful, I guess that the cleanup that
Nick evocated iwould be the path to follow, wouldn't it ?
thanks,
Regards,
Pascal
Le 02/07/2013 23:32, Nick Coghlan a écrit :
On 3 Jul 2013 04:34, "Pascal Chambon&
Hello everyone,
I'd like to bring your attention to this issue, since it touches the
fundamentals of python's import workflow:
http://bugs.python.org/issue17716
/I've tried to post it on the python-import ML for weeks, but it must
still be blocked somewhere in a moderation queue, so here I co
Greg Ewing a écrit :
Pascal Chambon wrote:
I don't follow you there - in my mind, the default __getattribute__
could simply have wrapped all its operations inside soem kind of
"try..catch AttributeError:" mechanism, and thus been able to
fallback to __getattr__ in any way
Michael Foord a écrit :
On 20/03/2010 12:00, Pascal Chambon wrote:
But the point which for me is still unclear, is : does the default
implementation of __getattribute__ (the one of "object") call
__getattr__ by himself, or does it rely on its caller for that, by
raising an Attr
Michael Foord a écrit :
On 19/03/2010 18:58, Pascal Chambon wrote:
Hello
I've already crossed a bunch of articles detailing python's attribute
lookup semantic (__dict__, descriptors, order of base class
traversing...), but I have never seen, so far, an explanation of
WHICH metho
Hello
I've already crossed a bunch of articles detailing python's attribute
lookup semantic (__dict__, descriptors, order of base class
traversing...), but I have never seen, so far, an explanation of WHICH
method did waht, exactly.
I assumed that getattr(a, b) was the same as a.__getattribu
hing about your question?
--Guido
On Thu, Feb 18, 2010 at 1:59 PM, Pascal Chambon
wrote:
Hello,
As I continue experimenting with advanced streams, I'm currently beginning
an important modification of io's Buffered and Text streams (removal of
locks, adding of methods...), to fit th
Hello,
As I continue experimenting with advanced streams, I'm currently
beginning an important modification of io's Buffered and Text streams
(removal of locks, adding of methods...), to fit the optimization
process of the whole library.
However, I'm now wondering what the idea is behind the 3
Hello
Some update about the spawnl() thingy ;
I've adapted the win32 code to have a new unix Popen object, which works
with a spawn() semantic. It's quite straightforward, and the
mutiprocessing call of a python functions works OK.
But I've run into some trouble : synchronization primitives.
x27;s not impossible that some
other OSes also rely on specific file handles (only emulating C file
descriptors for compatibility).
I've indeed mirrored the fileno concept, with a "handle" argument for
constructors, and a handle() getter.
On Fri, Feb 5, 2010 at 5:28 AM, Antoine
Hello
The new modular io system of python is awesome, but I'm running into
some of its limits currently, while replacing the raw FileIO with a more
advanced stream.
So here are a few ideas and questions regarding the mechanisms of this
IO system. Note that I'm speaking in python terms, but the
Matt Knox a écrit :
Jesse Noller gmail.com> writes:
We already have an implementation that spawns a
subprocess and then pushes the required state to the child. The
fundamental need for things to be pickleable *all the time* kinda
makes it annoying to work with.
just a lurker here...
The word "dogma" is a good one in this context however. "We" ( ;-)) have
accepted and promoted the dogma that multiprocessing is the solution to
parallelism in the face of the GIL. While it needn't be applicable in any and
every situation, we should make it so that it is applicable often enou
Although I would be in favor of an atfork callback registration system
(similar to atexit), it seems there is no way to solve the fork()
problem automatically with this. Any attempt to acquire/release locks
automatically will lead to deadlocks, as it is necessary to know the
exact program wor
So, if a patch was proposed for the multiprocessing, allowing an unified
"spawnl", thread-safe, semantic, do you think something could prevent
its integration ?
We may ignore the subprocess module, since fork+exec shouldn't be
bothered by the (potentially disastrous) state of child process d
ms, at
least). This issue led to the creation of python-atfork by the way.
Stefan Behnel a écrit :
Stefan Behnel, 30.01.2010 07:36:
Pascal Chambon, 29.01.2010 22:58:
I've just recently realized the huge problems surrounding the mix of
multithreading and fork() - i.e that only
ms, at
least). This issue led to the creation of python-atfork by the way.
Stefan Behnel a écrit :
Stefan Behnel, 30.01.2010 07:36:
Pascal Chambon, 29.01.2010 22:58:
I've just recently realized the huge problems surrounding the mix of
multithreading and fork() - i.e that only
which don't require fork-based
multiprocessing and its huge sharing of process data (in my opinion,
inheriting file descriptors is all a child process can require from its
parent.
Does it make sense to you ?
Regards,
Pascal Chambon
___
Python-Dev mail
+-InvalidFileNameError (filepath max lengths, or "? / : " characters
in a windows file name...)
This might be a bit too precise. Unix just has EINVAL, which
covers any kind of invalid parameter, not just file names.
Allright thanks, an InvalidParameter (or similar) exception should do it
Antoine Pitrou a écrit :
Hello,
So here is the proposed semantic, which matches established conventions:
*IOBase.truncate(n: int = None) -> int*
[...]
I still don't think there is a sufficient benefit in breaking
compatibility. If you want the file pointer to remain the same, you ca
Found in current io PEP :
Q: Do we want to mandate in the specification that switching between
reading and writing on a read-write object implies a .flush()? Or is
that an implementation convenience that users should not rely on?
-> it seems that the only important matter is : file pointer posit
Hello
Below is a corrected version of the PEP update, adding the start/end
indexes proposition and fixing functions signatures. Does anyone
disagree with these specifications ? Or can we consider it as a target
for the next versions of the io module ?
I would have no problem to implement this
Daniel Stutzbach a écrit :
On Sun, Sep 20, 2009 at 4:48 AM, Pascal Chambon
mailto:chambon.pas...@gmail.com>> wrote:
*RawIOBase*.readinto(b: bytes) -> int
"bytes" are immutable. The signature is:
*RawIOBase*.readinto(b: bytearray) -> int
Your efforts in worki
Hello
After weighing up here and that, here is what I have come with. Comments
and issue notifications more than welcome, of course. The exception
thingy is not yet addressed.
Regards,
Pascal
*Truncate and file pointer semantics*
Rationale :
The current implementation of truncate() always
What we could do with is better platform-independent
ways of distinguishing particular error conditions,
such as file not found, out of space, etc., either
using subclasses of IOError or mapping error codes
to a set of platform-independent ones.
Well, mapping all errors (including C ones and
Well, system compatibility argues strongl in favor of not letting
filepointer > EOF.
However, is that really necessary to move the pointer to EOF in ANY case
? I mean, if I extend the file, or if I reduce it without going lower
than my current filepointer, I really don't expect at all the io sys
Antoine Pitrou a écrit :
Hello,
Pascal Chambon gmail.com> writes:
@pitrou: non-blocking IO in python ? which ones are you thinking about ?
I was talking about the existing support for non-blocking IO in the FileIO class
(look up EAGAIN in fileio.c), as well as in the Buffe
@pitrou: non-blocking IO in python ? which ones are you thinking about ?
I have currently no plan to work on asynchronous IO like win32's
readFileEx() etc. (too many troubles for the benefit), however I'd be
interested by getting non-blocking operations on IPC pipes (I've crossed
several peopl
or "file already locked by another
process")
Regards,
Pascal
Daniel Stutzbach a écrit :
On Sat, Sep 19, 2009 at 2:46 AM, Pascal Chambon
mailto:chambon.pas...@gmail.com>> wrote:
This reimplementation is actually necessary to get file locking,
because advanced win32
@pitrou: non-blocking IO in python ? which ones are you thinking about ?
I have currently no plan to work on asynchronous IO like win32's
readFileEx() etc. (too many troubles for the benefit), however I'd be
interested by getting non-blocking operations on IPC pipes (I've crossed
several peopl
Hello everyone
I'm currently working on a reimplementation of io.FileIO, which would
allow cross-platform file range locking and all kinds of other safety
features ; however I'm slightly stuck due to some specification
fuzziness in the IO docs.
CF http://bugs.python.org/issue6939
The mai
Allright then, I understand the problem...
Thanks a lot,
regards,
Pascal
___
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
Hello snakemen and snakewomen
I'm Pascal Chambon, a french engineer just leaving my Telecom School,
blatantly fond of Python, of its miscellaneous offsprings and of all
what's around dynamic languages and high level programming concepts.
I'm currently studying all I can fi
35 matches
Mail list logo
