Le Tue, 08 Jan 2013 10:28:25 +0100,
"Yury V. Zaytsev" a écrit :
> On Mon, 2012-05-07 at 21:49 +0200, Antoine Pitrou wrote:
> >
> > I guess a long time ago, threading support in operating systems
> > wasn't very widespread, but these days all our supporte
Le Tue, 8 Jan 2013 09:02:00 -0500,
Trent Nelson a écrit :
> [ Weird, I can't see your original e-mail Antoine; hijacking
> Yury's reply instead. ]
The original e-mail is quite old (it was sent in May) :-)
Regards
Antoine.
___
Python-Dev mailing
Hi Yuriy,
For the record, it isn't necessary to cross-post. python-ideas is
the place for discussing this, and most interested people will be
subscribed to both python-ideas and python-dev, and therefore they get
duplicate messages.
Regards
Antoine.
Le Wed, 9 Jan 2013 05:14:02 +0400,
Yuriy Ta
Hello,
Le Wed, 9 Jan 2013 13:48:49 +0100,
Victor Stinner a écrit :
>
> Until recently (2011-05-24, issue #5715), the listening socket was not
> closed after fork for the ForkingMixIn flavor. This caused two issues:
> it's a security leak, and it causes "address already in use" error if
> the se
Le Thu, 10 Jan 2013 11:35:29 +0100,
Charles-François Natali a écrit :
> > So, I read your e-mail again and I'm wondering if you're making a
> > logic error, or if I'm misunderstanding something:
> >
> > 1. first you're talking about duplicate file or socket objects after
> > *fork()* (which is an
Le Thu, 10 Jan 2013 12:59:02 +0100,
Victor Stinner a écrit :
> 2013/1/10 Charles-François Natali :
> > Disclaimer: I'm not saying we should be changing all FDs to
> > close-on-exec by default like Ruby did, I'm just saying that
> > there's a real problem.
>
> I changed my mind, the PEP does not
On Thu, 10 Jan 2013 12:47:23 -0500
Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 01/10/2013 07:52 AM, Antoine Pitrou wrote:
> > Le Thu, 10 Jan 2013 12:59:02 +0100, Victor Stinner
> > a écrit :
> >
> >> 2013/1/10 Charles-Fran
On Fri, 11 Jan 2013 04:20:21 +0100 (CET)
ezio.melotti wrote:
>
> diff --git a/Lib/test/test_crypt.py b/Lib/test/test_crypt.py
> --- a/Lib/test/test_crypt.py
> +++ b/Lib/test/test_crypt.py
> @@ -1,7 +1,11 @@
> from test import support
> import unittest
>
> -crypt = support.import_module('crypt
On Sun, 13 Jan 2013 21:13:42 +1000
Nick Coghlan wrote:
> >
> > Also, ISTM that Windows also supports this flag. If it does, then
> > "cloexec" might not be the best name, because it refers to the
> > execve() Unix system call. Maybe something like "noinherit" would be
> > clearer (although coming
On Sun, 13 Jan 2013 21:33:30 +1000
Nick Coghlan wrote:
> On Sun, Jan 13, 2013 at 9:15 PM, Antoine Pitrou wrote:
> >> It also means we're free to implement a mechanism that tries to close
> >> all sensitive file descriptors in _PyOS_AfterFork.
> >
> > Ouch! T
On Sun, 13 Jan 2013 22:44:06 +1000
Nick Coghlan wrote:
> On Sun, Jan 13, 2013 at 9:43 PM, Antoine Pitrou wrote:
> > As for the opacity, feel free to propose something better
> > ("close_on_spawn", whatever). But I'm definitely and strongly -1
> > on "
On Sun, 13 Jan 2013 23:49:32 +1000
Nick Coghlan wrote:
>
> > (it's not even just a security issue: letting a bound socket open and
> > therefore being unable to re-use the same port is a bug even when
> > security is not a concern)
>
> Agreed, but it's the security implications that let us even
Le Sun, 13 Jan 2013 19:58:52 -0700,
Bruce Sherwood a écrit :
> Since this was copied to the Python-Dev list, I want to go on record
> as stating firmly that there is no evidence whatsoever to
> substantiate claims that there has ever been some kind of conflict
> between VPython and Python.
>
> S
On Mon, 21 Jan 2013 12:06:25 +0100 (CET)
serhiy.storchaka wrote:
> diff --git a/Lib/test/test_ucn.py b/Lib/test/test_ucn.py
> --- a/Lib/test/test_ucn.py
> +++ b/Lib/test/test_ucn.py
> @@ -144,13 +144,14 @@
> # very very long bogus character name
> try:
> x = b'\\N{SP
Hello,
I've upgraded the Mercurial version on hg.python.org. If there any
problems, don't hesitate to post here.
(apart from the connectivity problems we seem to have from time to time
and which shouldn't be related)
Regards
Antoine.
___
Python-Dev
On Wed, 23 Jan 2013 20:41:11 +0100
"Amaury Forgeot d'Arc" wrote:
> 2013/1/22 Antoine Pitrou
>
> > I've upgraded the Mercurial version on hg.python.org. If there any
> > problems, don't hesitate to post here.
> >
>
> I've noticed
On Wed, 23 Jan 2013 21:36:21 +0100
"Amaury Forgeot d'Arc" wrote:
> 2013/1/23 Antoine Pitrou
>
> > On Wed, 23 Jan 2013 20:41:11 +0100
> > "Amaury Forgeot d'Arc" wrote:
> > > 2013/1/22 Antoine Pitrou
> > >
> >
Le Wed, 23 Jan 2013 17:37:53 -0500,
David Bolen a écrit :
> Antoine Pitrou writes:
>
> > I've upgraded the Mercurial version on hg.python.org. If there any
> > problems, don't hesitate to post here.
> > (apart from the connectivity problems we seem to ha
Le Fri, 25 Jan 2013 12:28:10 +0100,
Victor Stinner a écrit :
> > I think the default behaviour needs to be configurable from the
> > environment and the command line, but I don't believe it should be
> > configurable from within the interpreter.
>
> sys.setdefaultcloexec() is convinient for unit
Hello,
On Sat, 26 Jan 2013 11:55:12 +0100
Stefan Krah wrote:
>
> I've subverted the build master authority on the FreeBSD-9.0 bot by
> exporting with_doc_strings=no. This is to test #16143 and #10156.
Well... Speaking personally, I'd much rather stop shipping and
"supporting" such obscure buil
On Sun, 27 Jan 2013 01:07:14 +1000
Nick Coghlan wrote:
> On Sun, Jan 27, 2013 at 12:45 AM, Antoine Pitrou wrote:
> >
> > Hello,
> >
> > On Sat, 26 Jan 2013 11:55:12 +0100
> > Stefan Krah wrote:
> >>
> >> I've subverted the build m
On Sat, 26 Jan 2013 17:03:59 +0100
Stefan Krah wrote:
> Stefan Krah wrote:
> > I'm not sure how accurate the output is for measuring these things, but
> > according to ``ls'' and ``du'' the option is indeed quite worthless:
> >
> > ./configure CFLAGS="-Os -s" LDFLAGS="-s" && make
> > 1.8M Jan
On Sun, 27 Jan 2013 10:56:51 +0100
Charles-François Natali wrote:
> Hi,
>
> What's exactly the guideline for choosing between the "Library" and
> "Extension modules" section when updating Misc/NEWS?
> Is it just the fact that the modified files live under Lib/ or Modules/?
>
> I've frequently ma
On Sun, 27 Jan 2013 12:23:15 +0100
Victor Stinner wrote:
> 2013/1/27 Guido van Rossum :
> > I had missed this detail. I agree that it should be exposed in the
> > interpreter. To my mind it is more like PYTHONPATH (which corresponds
> > roughly to sys.path manipulations) than like -R (which change
Le Sun, 27 Jan 2013 21:30:23 +0100,
Stefan Behnel a écrit :
> Serhiy Storchaka, 27.01.2013 17:52:
> > Is Boost Software License [1] compatible with Python license? Can I
> > steal some code from Boost library [2]?
> >
> > [1] http://www.boost.org/LICENSE_1_0.txt
> > [2] http://www.boost.org/
>
>
Hi,
Le Mon, 28 Jan 2013 11:01:05 +0100,
Lennart Regebro a écrit :
> This function takes a name string that must be a string specifying a
> valid zoneinfo time zone, i.e. "US/Eastern", "Europe/Warsaw" or
> "Etc/GMT".
Will non-ambiguous shorthands such as "Warsaw" and "GMT" be accepted?
> The ``
Le Mon, 28 Jan 2013 22:31:29 +1000,
Nick Coghlan a écrit :
>
> >> 6. Under "New collections"
> >>
> >> Why both lists and sets?
> >
> > Because pytz did it. But yes, you are right, an ordered set is a
> > better solution. Baseing it on OrderedDict seems like a hack,
> > though. I could implement
On Tue, 29 Jan 2013 01:17:35 +0100
Ralf Schmitt wrote:
> Guido van Rossum writes:
>
> >
> > On Mon, Jan 28, 2013 at 1:56 PM, Ralf Schmitt wrote:
> >
> >> Guido van Rossum writes:
> >>
> >> > Yeah, so the answer to all this is that 3rd party libraries know better
> >> > than to mess with global
Le Tue, 29 Jan 2013 09:35:40 +0100,
Ralf Schmitt a écrit :
> Antoine Pitrou writes:
>
> > Yes, it's fine, because an application developer can often control
> > (or at least study) the behaviour of all the code involved.
>
> I'd rather not have to check if so
Le Tue, 29 Jan 2013 11:24:49 +0100,
Ralf Schmitt a écrit :
> Please just acknowledge that having a global configurable setting may
> lead to problems.
Ralf, I won't "acknowledge" anything just so that it makes you
feel better. Your point has been made and has also been rebutted.
Let's agree to di
Le Wed, 30 Jan 2013 13:26:08 -0800,
Guido van Rossum a écrit :
> Thoughts on os.path? What happened to the idea of a new path object?
I plan to launch another round of discussions following the changes in
PEP 428.
Regards
Antoine.
>
> --Guido
>
>
> -- Forwarded message --
>
On Thu, 31 Jan 2013 23:52:27 +0100 (CET)
matthias.klose wrote:
> http://hg.python.org/cpython/rev/8ee6d96a1019
> changeset: 81859:8ee6d96a1019
> branch: 2.7
> parent: 81855:df9f8feb7444
> user:d...@python.org
> date:Thu Jan 31 23:52:03 2013 +0100
> summary:
> - Issue
On Fri, 1 Feb 2013 04:20:46 +0100 (CET)
ezio.melotti wrote:
>
> diff --git a/Doc/glossary.rst b/Doc/glossary.rst
> --- a/Doc/glossary.rst
> +++ b/Doc/glossary.rst
> @@ -320,7 +320,8 @@
>All of Python's immutable built-in objects are hashable, while no
> mutable
>containers (such
On Fri, 1 Feb 2013 11:00:24 +1000
Nick Coghlan wrote:
> On Fri, Feb 1, 2013 at 9:50 AM, Antoine Pitrou wrote:
> > On Thu, 31 Jan 2013 23:52:27 +0100 (CET)
> > matthias.klose wrote:
> >> http://hg.python.org/cpython/rev/8ee6d96a1019
> >> changeset: 81859:8
Le Fri, 1 Feb 2013 15:18:39 +0100,
"Amaury Forgeot d'Arc" a écrit :
> 2013/2/1 Charles-François Natali
>
> > >> dup2(oldfd, newfd) closes oldfd.
> > >
> > > No, it doesn't close oldfd.
> > >
> > > It may close newfd if it was already open.
> >
> > (I guess that's what he meant).
> >
> > Anyway,
On Fri, 1 Feb 2013 15:25:27 -0800
"Gregory P. Smith" wrote:
> On Fri, Feb 1, 2013 at 7:22 AM, Antoine Pitrou wrote:
>
> > Le Fri, 1 Feb 2013 15:18:39 +0100,
> > "Amaury Forgeot d'Arc" a écrit :
> > > 2013/2/1 Charles-François Nata
On Sun, 3 Feb 2013 16:44:33 +1000
Nick Coghlan wrote:
> On Sun, Feb 3, 2013 at 4:37 PM, Guido van Rossum wrote:
> > I don't know or care much about PyPI metadata, so do what you feel is
> > right. If you are uncomfortable being PEP-uncle *and* -author, find
> > another author or another uncle. Bu
On Sun, 3 Feb 2013 12:34:36 +
Paul Moore wrote:
>
> So it's perfectly possible to use wheels right now, without the pip
> integration. But the pip developers don't want to integrate the wheel
> format just because it exists - they want the assurance that it's an
> accepted format supported by
On Sun, 3 Feb 2013 23:08:04 +1000
Nick Coghlan wrote:
> On Sun, Feb 3, 2013 at 10:48 PM, Antoine Pitrou wrote:
> > On Sun, 3 Feb 2013 12:34:36 +
> > Paul Moore wrote:
> >>
> >> So it's perfectly possible to use wheels right now, without the pip
> >
On Sun, 3 Feb 2013 09:41:29 -0500
Daniel Holth wrote:
> The neat thing about wheel is that you can install them without having the
> software used to build them. So we might try to provide a very simple wheel
> installer script with Python that did not even depend on DistUtils. You
> would be able
Le Sun, 3 Feb 2013 19:11:36 -0500,
Benjamin Peterson a écrit :
> As you may have noticed, no 2.7.4 rc has been created yet. Yesterday,
> the buildbots were all red, and release blocker issues had to be dealt
> with. Today, I was not as availabIe and people were fixing
> important-looking crashers.
Le Mon, 04 Feb 2013 21:04:39 +0100,
Matthias Klose a écrit :
> So what I do understand, build-related issues like an arm64 or
> mingw32 port are ok for 2.7, if they are stable on the trunk, and
> communicated on python-dev?
Making Python build on a new platform is, AFAICT, considered a new
featur
Le Wed, 6 Feb 2013 16:08:39 -0500,
Barry Warsaw a écrit :
> On Feb 06, 2013, at 02:38 PM, Antoine Pitrou wrote:
>
> >Le Mon, 04 Feb 2013 21:04:39 +0100,
> >Matthias Klose a écrit :
> >> So what I do understand, build-related issues like an arm64 or
> >> ming
Le Thu, 7 Feb 2013 20:02:39 +1000,
Nick Coghlan a écrit :
> On 7 Feb 2013 19:13, "Antoine Pitrou" wrote:
> >
> > Le Wed, 6 Feb 2013 16:08:39 -0500,
> > Barry Warsaw a écrit :
> > > On Feb 06, 2013, at 02:38 PM, Antoine Pitrou wrote:
> &g
Hi,
On Thu, 7 Feb 2013 23:33:46 +0800
LittleQ wrote:
>
> PyCon Taiwan is calling for proposals now, Python is becoming one of famous
> programming languages in Taiwan, We need every Python developers'
> participating. Go to the link above, and submit your proposal right now! :D
>
> Feel free t
Le Fri, 08 Feb 2013 10:58:36 +,
Chris Withers a écrit :
> Hi All,
>
> Where would I look to find out which release a fix for an issue
> (http://bugs.python.org/issue15822 if you're interested ;-)) will
> land in?
Just read that issue's comments and you'll know in which branches the
fix was
Le Fri, 08 Feb 2013 12:45:48 +,
Chris Withers a écrit :
> On 08/02/2013 11:17, Antoine Pitrou wrote:
> > Le Fri, 08 Feb 2013 10:58:36 +,
> > Chris Withers a écrit :
> >> Hi All,
> >>
> >> Where would I look to find out which release a fix
On Sun, 10 Feb 2013 22:32:50 +1000
Nick Coghlan wrote:
>
> Replaces many use cases for dynamic setting of ``__metaclass__``
> -
>
> For use cases that don't involve completely replacing the defined class,
> Python 2 code that dynami
On Sun, 10 Feb 2013 23:17:00 +1000
Nick Coghlan wrote:
> On Sun, Feb 10, 2013 at 10:47 PM, Antoine Pitrou wrote:
> > On Sun, 10 Feb 2013 22:32:50 +1000
> > Nick Coghlan wrote:
> >>
> >> Replaces many use cases for d
On Mon, 11 Feb 2013 00:09:55 +1000
Nick Coghlan wrote:
>
> As far as the maintenance burden goes, the patch to enable PEP 422 for
> types.new_class() is trivial:
>
> -return meta(name, bases, ns, **kwds)
> +cls = meta(name, bases, ns, **kwds)
> +try:
> +initcl = cls.__init_cl
On Sun, 10 Feb 2013 16:27:49 -0500
PJ Eby wrote:
> On Sun, Feb 10, 2013 at 7:32 AM, Nick Coghlan wrote:
> >class Example:
> >@classmethod
> >def __init_class__(cls):
>
> Is the @classmethod required? What happens if it's not present?
>
> Second, will type have a default __i
Le Mon, 11 Feb 2013 10:15:36 -0500,
Barry Warsaw a écrit :
> On Feb 10, 2013, at 03:28 PM, Antoine Pitrou wrote:
>
> >Sure, every little addition is "trivial". At the end you have a scary
> >monster made of many little trivial additions along the years, and
> &g
On Mon, 11 Feb 2013 22:07:50 +0300
anatoly techtonik wrote:
> On Mon, Feb 11, 2013 at 9:27 PM, Guido van Rossum wrote:
>
> > Anatoly, stop this discussion *NOW*. It is not appropriate for python-dev
> > and you risk being banned from python-dev if you keep it up.
> >
>
> It is not a problem for
Le Mon, 11 Feb 2013 11:02:04 -0800,
Guido van Rossum a écrit :
> Warning: see http://bugs.python.org/issue17170. Depending on the
> length of the string being scanned and the probability of finding the
> specific character, the proposed change could actually be a
> *pessimization*. OTOH if the cha
Hi !
On Tue, 12 Feb 2013 23:03:04 +0200
Maciej Fijalkowski wrote:
>
> We recently encountered a performance issue in stdlib for pypy. It
> turned out that someone commited a performance "fix" that uses += for
> strings instead of "".join() that was there before.
>
> Now this hurts pypy (we can
On Tue, 12 Feb 2013 13:32:50 -0800
"fwierzbi...@gmail.com" wrote:
> On Tue, Feb 12, 2013 at 1:03 PM, Maciej Fijalkowski wrote:
> > Hi
> >
> > We recently encountered a performance issue in stdlib for pypy. It
> > turned out that someone commited a performance "fix" that uses += for
> > strings in
On Tue, 12 Feb 2013 16:40:38 -0500
Ned Batchelder wrote:
>
> But the only reason "".join() is a Python idiom in the first place is
> because it was "the fast way" to do what everyone initially coded as "s
> += ...". Just because we all learned a long time ago that joining was
> the fast way
On Wed, 13 Feb 2013 00:28:15 +0100
Christian Heimes wrote:
> Am 12.02.2013 22:32, schrieb Antoine Pitrou:
> > For the record, io.StringIO should be quite fast in 3.3.
> > (except for the method call overhead that Guido is complaining
> > about :-))
>
> AFAIK it
On Wed, 13 Feb 2013 09:39:23 +1000
Nick Coghlan wrote:
> On 13 Feb 2013 07:08, "Maciej Fijalkowski" wrote:
> >
> > Hi
> >
> > We recently encountered a performance issue in stdlib for pypy. It
> > turned out that someone commited a performance "fix" that uses += for
> > strings instead of "".join
On Wed, 13 Feb 2013 08:16:21 +0100
Antoine Pitrou wrote:
> On Wed, 13 Feb 2013 09:39:23 +1000
> Nick Coghlan wrote:
> > On 13 Feb 2013 07:08, "Maciej Fijalkowski" wrote:
> > >
> > > Hi
> > >
> > > We recently encountered a performance
Le Wed, 13 Feb 2013 09:02:07 +0100,
Victor Stinner a écrit :
> I added a _PyUnicodeWriter internal API to optimize str%args and
> str.format(args). It uses a buffer which is overallocated, so it's
> basically like CPython str += str optimization. I still don't know how
> efficient it is on Windows
On Wed, 13 Feb 2013 20:48:08 +0200
Maciej Fijalkowski wrote:
>
> Things were pypy differs:
>
> * finalizers in pypy will be called only once, even if the object is
> resurrected. I'm not sure if this is detail or we're just plain
> incompatible.
I think this should be a detail.
> * pypy breaks
On Wed, 13 Feb 2013 20:30:18 +0100
Armin Rigo wrote:
> Hi,
>
> On Wed, Feb 13, 2013 at 8:22 PM, Maciej Fijalkowski wrote:
> > I think it's well documented you should not rely on stuff like that
> > being run at the exit of the interpreter.
>
> Actually right now, at the exit of the interpreter,
On Thu, 14 Feb 2013 01:21:40 +0100
Victor Stinner wrote:
>
> UnicodeWriter (using the "writer += str" API) is the fastest method in
> most cases, except for data = ['a'*10**4] * 10**2 (in this case, it's
> 8x slower!). I guess that the overhead comes for the overallocation
> which then require to
Le Wed, 13 Feb 2013 20:50:51 +,
Richard Oudkerk a écrit :
> On 13/02/2013 7:25pm, Antoine Pitrou wrote:
> > I think resurrecting objects from __del__ is crazy, so IMO what you
> > suggest is fine.
>
> You mean like subprocess.Popen.__del__? I quite agree.
Ouch. I d
(unlurking)
Le mardi 30 août 2005 à 23:20 +1000, Nick Coghlan a écrit :
> I momentarily forgot that "part" is also a verb in its own right, with the
> right meaning, too (think "parting your hair" and "parting the Red Sea").
"parts" sounds more obvious than the verb "part" which is little known
> Neat!
> +1 on regexps as an argument to partition().
It sounds better to have a separate function and call it re.partition,
doesn't it ?
By the way, re.partition() is *really* useful compared to re.split()
because with the latter you don't which string precisely matched the
pattern (it isn't an
Le mardi 30 août 2005 à 12:29 -0500, [EMAIL PROTECTED] a écrit :
> Just group your re:
>
> >>> import re
> >>>
> >>> re.split("ab", "abracadabra")
> ['', 'racad', 'ra']
> >>> re.split("(ab)", "abracadabra")
> ['', 'ab', 'racad', 'ab', 'ra']
>
> and you get it in the retur
Le lundi 05 septembre 2005 à 16:52 +0100, Gareth McCaughan a écrit :
> ... and should add: Of course it's usually seen as being about
> output more than about formatting, but in fact if you want
> to do what Python does with "%", C with "sprintf" and
> Common Lisp with (format nil ...) then the Rig
> That sounds like a good idea. I'm certainly getting concerned about
> the proliferation of methods that people "should" add to file-like
> objects, where read/write are the only fundamental ones needed.
>
> I can't see mixins working, as too many file-like objects are written in C...
One could
(just my 2 cents)
Le mardi 06 septembre 2005 à 07:23 -0700, Guido van Rossum a écrit :
> On 9/6/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > printf('$1 forgot to frobnicate the $2!\n', username, file.name,
> >to=sys.stderr)
> Is it worth doing this and completely dropping the %-based f
Hi,
Le jeudi 08 septembre 2005 à 19:12 +0900, Stephen J. Turnbull a écrit :
> It would be
> nice to be able to lose the "_()" calls to gettext(). The function
> would look to see if a message catalog was available for the current
> output stream, and if not, do no translation.
That doesn't so
> This does make me think of the interesting prospect of an internationalised
> string literal, though (e.g., _"This an il8n string"). I'm not sure it would
> be enough of a win over the status quo though,
I don't think so either. i18n doesn't require its specific string
notation (in addition,
Le vendredi 09 septembre 2005 à 23:09 +1000, Neil Hodgson a écrit :
> Antoine Pitrou:
>
> > As for seamless unicode support, there are also problems sometimes with
> > filenames and filepaths: see e.g.
> > https://sourceforge.net/tracker/?func=detail&aid=12838
Hi,
> Brent's variation depends on the next probe position for a key being
> derivable just from the key and its current position. The use of
> perturbation in set_lookkey() prevents that, as we cannot say, given a
> key at a certain position, where the next probe location for that key
> would ha
> The best way to make people stop complaining about the GIL and start
> using
> process-based multiprogramming is to provide solid, standardized support
> for process-based multiprogramming.
100% agreed. I needed a portable way to know if a program was already
running (and then to send it a si
Hi,
> On *nix, use a unix domain socket (location in the filesystem which acts
> as a listening socket). On Windows, you can use cTypes, pywin32, etc.,
> to create a global mutex and/or COM interface.
Ok, but for a very simple and crude need like mine (the application code
using this IPC means
> The only problem is that it's not easy to come up with a regex-based
> way to transform
>
> C and X or Y
>
> into
>
> X if C else Y
(my 2 cents)
I find this proposal very confusing. The order is not logical at all.
One usually expects to find the condition on one side, and the
alter
> (C) That scheduler is non-preemptive. A single
> greedy generator can starve all the others.
Instead of looking at this as a problem, you could look at it as a
feature. Since generators can't be switched at arbitrary places, the
programmer has to define his/her synchronization points explicit
Le vendredi 30 septembre 2005 à 08:32 -0500, [EMAIL PROTECTED] a écrit :
> >> (C) That scheduler is non-preemptive. A single greedy generator can
> >> starve all the others.
>
> Antoine> Instead of looking at this as a problem, you could look at it
> Antoine> as a feature.
>
Le vendredi 30 septembre 2005 à 07:32 -0700, Simon Wittber a écrit :
> I use this approach extensively, using tasks which are defined using
> generators. The scheduler I developed for this can be viewed here:
>
> http://metaplay.dyndns.org:82/svn/nanothreads/nanothreads.py
FWIW, I've coded my ow
Hi,
> I've never heard
> someone complain that the GIL is in the way for these types of apps.
I've never said so either.
I was just saying that it can be useful to mix cooperative threading and
preemptive threading in the same app, i.e. have different domains of
cooperative threading which are p
Hi Jp,
Le vendredi 30 septembre 2005 à 12:20 -0400, Jp Calderone a écrit :
> "Advocating" might be putting it too strongly :) "Experimenting with"
> describes the current state of things most accurately.
Ok :)
> The problem it aims to solve is integration with cooperative threading
> systems w
Le lundi 03 octobre 2005 à 02:09 -0400, Martin Blais a écrit :
>
> What if we could completely disable the implicit conversions between
> unicode and str?
This would be very annoying when dealing with some modules or libraries
where the type (str / unicode) returned by a function depends on the
c
Le lundi 03 octobre 2005 à 14:59 +0200, Fredrik Lundh a écrit :
> Antoine Pitrou wrote:
>
> > A good rule of thumb is to convert to unicode everything that is
> > semantically textual
>
> and isn't pure ASCII.
How can you be sure that something that is /semanticall
Hi,
Josiah:
> > How can you be sure that something that is /semantically textual/ will
> > always remain "pure ASCII" ? That's contradictory, unless your software
> > never goes out of the anglo-saxon world (and even...).
>
> Non-unicode text input widgets.
You didn't understand my statement.
I
Hi,
Le lundi 03 octobre 2005 à 20:37 +0200, Fredrik Lundh a écrit :
> > If I have an unicode string containing legal characters greater than
> > 0x7F, and I pass it to a function which converts it to str, the
> > conversion fails.
>
> so? if it does that, it's not unicode safe.
[...]
> what's
> > If that's how things were designed, then Python's entire standard
> > brary (not to mention third-party libraries) is not "unicode safe" -
> > to quote your own words - since many functions may return 8-bit strings
> > containing non-ascii characters.
>
> huh? first you talk about functions
> Presumably in Python 3.0, opening a file in "text" mode will require an
> encoding to be specified, and opening it in "binary" mode will cause it to
> produce or consume byte arrays, not strings. This should apply to sockets
> too, and really any I/O facility, including GUI frameworks, DBAPI
Le lundi 03 octobre 2005 à 14:02 -0700, Guido van Rossum a écrit :
> On 10/3/05, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> > Could the "bytes" type be just the same as the current "str" type but
> > without the implicit unicode conversion ? Or am
Le lundi 03 octobre 2005 à 17:42 -0700, Guido van Rossum a écrit :
> I don't see a use case for replace.
Agreed.
> Alternatively, you could always specify Latin-1 as the encoding and
> convert it that way -- I don't think there's any input that can cause
> Latin-1 decoding to fail.
You seem to
Hi,
(my 2 cents, probably not very constructive)
> Recently, I've been simulating high concurrency on a PostgreSQL
> database, and I've discovered that the way you reason about row and
> table locks is very similar to the way you reason about locking among
> threads. The big difference is th
> Well, I think you just described ZODB. ;-)
*gasp*
> I'd be happy to explain how
> ZODB solves those problems, if you're interested.
Well, yes, I'm interested :)
(I don't anything about Zope internals though, and I've never even used
it)
___
Pyth
Le dimanche 09 octobre 2005 à 07:46 -0700, Guido van Rossum a écrit :
> I
> also think that using a thread for async I/O is the wrong approach --
> if you wanted to use threads shou should be using threads and you
> wouldn't be dealing with generators. There's a solution that uses
> select() which
(my own 2 eurocents)
> I do feel that for Python 3 it might be better to make a clean
> separation between keywords and positionals: in other words, of the
> function definition specifies a keyword argument then a keyword must be
> used to present it.
Do you mean it would also be forbidden to
> Maybe Queue belongs in a module called synchronize to avoid any confusions.
Why not /just/ make the doc a little bit more explicit ?
Instead of saying:
It is especially useful in threads programming when information
must be exchanged safely between multiple threads.
Replace it w
> unfortunately, this standard seem to result in generic "spamtools" modules
> into which people throw everything that's even remotely related to "spam",
> followed by complaints about bloat and performance from users, followed by
> various more or less stupid attempts to implement lazy loading of
>class Demo(object):
> @def_property
> class test:
> """This is a test property"""
> def get(self):
> print "Getting attribute on instance"
> def set(self, value):
> print "Setting attribute on instance"
> def dele
Le mardi 18 octobre 2005 à 10:57 -0400, Barry Warsaw a écrit :
> On Mon, 2005-10-17 at 23:46, Guido van Rossum wrote:
>
> > But I still like the version with strings better:
> >
> > x = property('get_x', 'set_x')
> >
> > This trades two lambdas for two pairs of string quotes; a good deal IMO
> What would this mythical block statement look like that would make
> properties easier to write than the above late-binding or the subclass
> Property recipe?
I suppose something like:
class C(object):
x = prop:
""" Yay for property x! """
def __get__(self):
4801 - 4900 of 4909 matches
Mail list logo
