On 08/12/11 18:03, eric.araujo wrote:
> http://hg.python.org/cpython/rev/1b818f3639ef
> changeset: 71826:1b818f3639ef
> branch: 3.2
> parent: 71823:8032ea4c3619
> user:Éric Araujo
> date:Wed Aug 10 02:01:32 2011 +0200
> summary:
> Fix find command in makefile “funny”
Guido van Rossum, 12.08.2011 23:38:
On Fri, Aug 12, 2011 at 12:57 PM, Rene Nejsum wrote:
I think I understand the background and need for GIL. Without it Python
programs would have been cluttered with lock/synchronized statements and
C-extensions would be harder to write.
No, sorry, the first
Sturla Molden wrote:
With one interpreter per thread, and
a malloc that does not let threads share memory pages (one heap per
thread), Python could do the same.
Wouldn't that be more or less equivalent to running
each thread in a separate process?
--
Greg
_
Terry Reedy writes:
> But multiple compound-noun adjectives are awkward and the above is ugly.
> Would "Command-line library for parsing options and arguments" fit?
Better, but the binding is still wrong. The “command-line” should
instead be a modifier for “options and arguments”.
So:
Libr
On 8/12/2011 1:17 PM, Éric Araujo wrote:
With all due respect to the fact that you’re a native speaker and I’m
not, here I disagree because I parse the sentence in this way (using
parens to group things by precedence, if you want):
You are right, I misparsed without considering the full contex
Thank you for the clarification, I should have been more precise...
On 12/08/2011, at 23.38, Guido van Rossum wrote:
> On Fri, Aug 12, 2011 at 12:57 PM, Rene Nejsum wrote:
>> I think I understand the background and need for GIL. Without it Python
>> programs would have been cluttered with lock/s
At 05:03 PM 8/12/2011 -0400, Glyph Lefkowitz wrote:
Are there any rules about passing invalid identifiers to __import__
though, or is that just less likely? :)
I suppose you have a point there. ;-)
I still like the idea of a 'marker' file. It would be great if
there were a new marker like
On Thu, Aug 11, 2011 at 6:05 PM, Terry Reedy wrote:
> There was no comparable transition. Python 2.0 was basically 1.6 renamed for
> a different distributor.
No that's not true. If you compare the "what's new" sections there is
quite a large difference between 1.6 and 2.0, despite being released
On Fri, Aug 12, 2011 at 12:57 PM, Rene Nejsum wrote:
> I think I understand the background and need for GIL. Without it Python
> programs would have been cluttered with lock/synchronized statements and
> C-extensions would be harder to write.
No, sorry, the first half of this is incorrect: with o
On Aug 12, 2011, at 2:33 PM, P.J. Eby wrote:
> At 01:09 PM 8/12/2011 -0400, Glyph Lefkowitz wrote:
>> Upon further reflection, PEP 402 _will_ make dealing with namespace packages
>> from this code considerably easier: we won't need to do AST analysis to look
>> for a __path__ attribute or anyth
On 2011-08-12, at 20:59 , Sturla Molden wrote:
> Den 12.08.2011 18:51, skrev Xavier Morel:
>> * Erlang uses "erlang processes", which are very cheap preempted *processes*
>> (no shared memory). There have always been tens to thousands to millions of
>> erlang processes per interpreter source co
On Fri, Aug 12, 2011 at 12:19:23PM -0400, Barry Warsaw wrote:
> On Aug 12, 2011, at 01:10 PM, Nick Coghlan wrote:
>
> >1. Accept the reality of that situation, and propose a mechanism that
> >minimises the impact of the resulting ambiguity on end users of Python
> >by allowing developers to be exp
Even in the Erlang model, the afore-mentioned issues of bus contention put a
cap on the number of threads you can run in any given application assuming
there's any amount of cross-thread synchronization. I wrote a blog post on
this subject with respect to my experience in tuning RabbitMQ on NUMA
ar
Den 12.08.2011 18:57, skrev Rene Nejsum:
My two danish kroner on GIL issues….
I think I understand the background and need for GIL. Without it
Python programs would have been cluttered with lock/synchronized
statements and C-extensions would be harder to write. Thanks to Sturla
Molden for he'
Den 12.08.2011 18:51, skrev Xavier Morel:
* Erlang uses "erlang processes", which are very cheap preempted
*processes* (no shared memory). There have always been tens to
thousands to millions of erlang processes per interpreter source
contention within the interpreter going back to pre-SMP by s
Could a core developer please review the patch I proposed for issue
12178 "csv writer doesn't escape escapechar"?
Thanks!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pytho
I think either
Command-line option- and argument-parsing library.
or
Command-line option and argument parsing library.
would be acceptable.
-Fred
--
Fred L. Drake, Jr.
"A person who won't read has no advantage over one who can't read."
--Samuel Langhorne Clemens
___
At 01:09 PM 8/12/2011 -0400, Glyph Lefkowitz wrote:
Upon further reflection, PEP 402 _will_ make dealing with namespace
packages from this code considerably easier: we won't need to do AST
analysis to look for a __path__ attribute or anything gross like
that improve correctness; we can just loo
On Aug 12, 2011, at 01:34 PM, R. David Murray wrote:
>True, but I think that is orthogonal to the purposes of the PEP, which
>is about supporting writing of system independent scripts that are *not*
>provided by the distribution (or installed via packaging). And PEP 397
>aims to extend that to Wi
On Fri, 12 Aug 2011 12:19:23 -0400, Barry Warsaw wrote:
> On Aug 12, 2011, at 01:10 PM, Nick Coghlan wrote:
> >1. Accept the reality of that situation, and propose a mechanism that
> >minimises the impact of the resulting ambiguity on end users of Python
> >by allowing developers to be explicit ab
Hi,
>> summary:
>>Use real word in English text (i.e. not code)
> I agree that 'arg' for 'argument is email/twitter-speak, not proper
> document prose.
>> - :synopsis: Command-line option and argument-parsing library.
>> + :synopsis: Command-line option and argument parsing library.
> Ho
On Aug 12, 2011, at 11:24 AM, P.J. Eby wrote:
> That is, the above code hardocdes a variety of assumptions about the import
> system that haven't been true since Python 2.3.
Thanks for this feedback. I honestly did not realize how old and creaky this
code had gotten. It was originally develo
My two danish kroner on GIL issues….
I think I understand the background and need for GIL. Without it Python
programs would have been cluttered with lock/synchronized statements and
C-extensions would be harder to write. Thanks to Sturla Molden for he's
explanation earlier in this thread.
Howe
Hi everyone,
I think it would be useful to have the “Porting Python 2 Code to Python
3” HOWTO in the 2.7 docs, as I think that a lot of users consult the 2.7
docs. Is there any reason not to do it?
Regards
___
Python-Dev mailing list
Python-Dev@python.
On 2011-08-11, at 21:11 , Sturla Molden wrote:
>
> (b) another threading model (e.g. one interpreter per thread, as in Tcl,
> Erlang, or .NET app domains).
Nitpick: this is not correct re. erlang.
While it is correct that it uses "another threading model" (one could even say
"no threading model
On Aug 12, 2011, at 01:10 PM, Nick Coghlan wrote:
>1. Accept the reality of that situation, and propose a mechanism that
>minimises the impact of the resulting ambiguity on end users of Python
>by allowing developers to be explicit about their target language.
>This is the approach advocated in PE
ACTIVITY SUMMARY (2011-08-05 - 2011-08-12)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open2923 (+24)
closed 21602 (+23)
total 24525 (+47)
Open issues wit
On Fri, 12 Aug 2011 09:32:23 -0500
VanL wrote:
> On 8/11/2011 2:11 PM, Sturla Molden wrote:
> >
> > (b) another threading model (e.g. one interpreter per thread, as in Tcl,
> > Erlang, or .NET app domains).
>
> We are close to this, in that we already have baked-in support for
> subinterpreters.
At 02:02 PM 8/11/2011 -0400, Glyph Lefkowitz wrote:
Rather than a one-by-one ad-hoc consideration of which attribute
should be set to None or empty strings or "" or what have
you, I'd really like to see a discussion in the PEP saying what a
package really is vs. what a module is, and what one c
On 8/11/2011 2:11 PM, Sturla Molden wrote:
(b) another threading model (e.g. one interpreter per thread, as in Tcl,
Erlang, or .NET app domains).
We are close to this, in that we already have baked-in support for
subinterpreters. Out of curiosity, why isn't this being pursued?
_
Hello,
Le vendredi 12 août 2011 à 14:32 +0200, Xavier Morel a écrit :
> On 2011-08-12, at 12:58 , Antoine Pitrou wrote:
> > Current protocol versions export object sizes for various built-in types
> > (str, bytes) as 32-bit ints. This forbids serialization of large data
> > [1]_. New opcodes are
On 2011-08-12, at 12:58 , Antoine Pitrou wrote:
> Current protocol versions export object sizes for various built-in types
> (str, bytes) as 32-bit ints. This forbids serialization of large data
> [1]_. New opcodes are required to support very large bytes and str
> objects.
How about changing obje
Hello,
This PEP is an attempt to foster a number of small incremental
improvements in a future pickle protocol version. The PEP process is
used in order to gather as many improvements as possible, because the
introduction of a new protocol version should be a rare occurrence.
Feel free to sugges
Éric Araujo netwok.org> writes:
> Besides, putting data files in a Python package is held very poorly by
> some (mostly people following the File Hierarchy Standard), and in
> distutils2/packaging, we (will) have a resources system that’s as
> convenient for users and more flexible for OS package
34 matches
Mail list logo
