On Tue, Aug 4, 2009 at 5:43 PM, Mark Hammond wrote:
> I'm more than willing to help on this; I haven't resurrected my stale patch
> because I find win32text only 1/2 a solution that doesn't work in practice.
> Therefore that patch is as stale for me as it is anyone. However, if a plan
> is put in
On Thu, Aug 6, 2009 at 4:47 AM, Nick Coghlan wrote:
> Option 2:
> x = float(string) except ValueError: float('nan')
> op(float(string) except ValueError: float('nan'))
>
> This has the virtue of closely matching the statement syntax, but
> embedding colons inside expressions is somewhat ugly. Yes
osted this to the python-ideas version of this thread already, but
since more people seem to be posting to the python-dev list I will
post it here as well
PEP:
Title: try-except conditional expressions
Version:
Last-Modified:
Author: Jeff McAninch , Dj Gilcrease
Discussions-To: pyth
On Tue, Aug 18, 2009 at 2:12 AM, "Martin v. Löwis" wrote:
> The second item is line conversion hooks. Dj Gilcrease has posted a
> solution which he considers a hack himself. Mark Hammond has also
> volunteered, but it seems some volunteer needs to be "in charge",
On Fri, Aug 21, 2009 at 1:16 AM, Mark Hammond wrote:
> Maybe you can enumerate what you think needs to change in mercurial, then
> once we have a plan in place it will be clearer who can do what.
The encode/decode hooks need to be passed the filename they are
working on so you can have an ignore l
On Fri, Aug 21, 2009 at 8:19 AM, Dirkjan Ochtman wrote:
> Enabling extensions in a versioned file is not going to fly.
any specific reason?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Fri, Aug 21, 2009 at 6:58 PM, Mark Hammond wrote:
> [encode]
> *.dsp=none:
> **=cleverencode:
>
> The end result should be that anything with 'none:' forms what you call an
> ignore list.
>
> Would that not meet your requirements?
It would, so I guess I'll hold off on digging into the hook cod
On Mon, Aug 24, 2009 at 2:01 PM, Bugbee, Larry wrote:
> I don't have a specific case in mind. In general, however, it would be
> nice to be able to protect intellectual property, but without addressing
> the problem from a holistic view, there is little protection afforded
> and perhaps a lot of u
Looking though the tests you have setup for ipaddr it is clear that
you want the following to be True
ip1 = ipaddr.IPv4Network('1.1.1.0/24')
ip2 = ipaddr.IPv4Network('1.1.1.1/24')
ip1 == ip2
based on this test
self.assertEquals(ip1.compare_networks(ip2), 0)
but your ><= operators all compare ag
On Mon, Sep 28, 2009 at 5:34 AM, R. David Murray wrote:
> The fundamental divide here is between two behaviors.
>
> ipaddr:
>
> >>> x = IPv4Network('192.168.1.1/24')
> >>> y = IPv4Network('192.168.1.0/24')
> >>> x == y
> False
> >>> x.ip
> IPv4Address('192.168.1.1')
>
> desired:
On Mon, Sep 28, 2009 at 8:04 AM, Daniel Stutzbach
wrote:
> On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan wrote:
>>
>> I should note that I've softened my position slightly from what I posted
>> yesterday. I could live with the following compromise:
>>
>> >>> x = IPv4Network('192.168.1.1/24')
>
On Mon, Sep 28, 2009 at 8:56 AM, Guido van Rossum wrote:
> Hold it right there! That's wrong. You can't have two objects that
> compare equal but whose hashes differ. It will break dict lookup. The
> other way around is fine: two objects may differ and still have the
> same hash.
mm I never knew
Ok updated patch so it meets the following conditions
>>> IPv4Network(192.168.1.1/24)
IPv4Network(192.168.1.0/24)
>>> x = IPv4Network('192.168.1.1/24')
>>> y = IPv4Network('192.168.1.0/24')
>>> x == y
True
>>> hash(x) == hash(y)
True
The ip you instantiated the Network with is still accessible t
I would recommend removing the class keyword and replacing it with the
() as you have in the custom examples or replacing () with class so it
is uniform across all config options
handlers:
file:
class : logging.handlers.RotatingFileHandler
formatter: precise
filename: logconfig.log
ma
2010/1/16 Jack Diederich :
> Good lord, did this make it past other people's spam filters too? I
> especially liked the reference to "REGION -2,0 ; Rlyeh". Ph'nglui
> mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn to you too sir.
Ya made it past mine too, it looks like a debug dump of a macro for a
s
http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/digitalxero%40gmail.com
>
--
Dj Gilcrease
OpenRPG Developer
~~http://www.openrpg.com
___
Python-Dev mailing list
Python-Dev@python.
ython? does it make
> any sense in that context? how do we make it not impossible for them
> to support?
>
> despite all the questions, I'm +1 on going ahead with a PEP and sprint
> discussions to figure out how to get it in for CPython 3.2 and 2.7.
>
> -gps
>
I have been playing with the feedback branch of this package for py3
and there seems to be a rather serious bug in the Process version.
Using the code @ http://dpaste.com/hold/168795/
When I was running in debug mode I found that as soon as
p = multiprocessing.Process(
I am also getting an odd error on odd error on exit
Error in atexit._run_exitfuncs:
TypeError: print_exception(): Exception expected for value, str found
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On Sat, Mar 6, 2010 at 2:58 PM, Jesse Noller wrote:
> Did you run the provided example code on windows by chance? If so, look at
> the multiprocessing docs, there are restrictions on windows (see the
> __main__ note) - not following the guidelines can result in lots of
> processes spawning.
Yes,
After playing with the API for a while & running into many issues with
the examples & tests crashing windows I decided to modify the API a
little and fix up the examples so they dont crash windows based
computers.
http://code.google.com/p/pythonfutures/issues/detail?id=1
API Change that changes t
On Sun, Mar 7, 2010 at 6:50 AM, Jesse Noller wrote:
> Making the tests and examples happy on windows is fine; but some
> explanation is needed for the API changes.
>
My primary motivation behind the API change is so there is just a
single public Executor class that you tell what system to use ins
On Mon, Mar 8, 2010 at 4:25 AM, Nick Coghlan wrote:
> Wouldn't a factory function serve that purpose just as well? Or even
> just "from concurrent.futures import ProcessPoolExecutor as TaskExecutor".
>
> That last form has the virtue that you can retrieve your executor from
> anywhere rather than
On Mon, Mar 8, 2010 at 12:04 PM, Dj Gilcrease wrote:
> A style I have used in my own code in the past is a Singleton class
> with register and create methods, where the register takes a
> name(string) and the class and the create method takes the name and
> *args, **kwargs and acts
On Mon, Mar 8, 2010 at 2:11 PM, wrote:
> Getting rid of the process-global state like this simplifies testing (both
> testing of the executors themselves and of application code which uses
> them). It also eliminates the unpleasant interpreter shutdown/module
> globals interactions that have pla
On Tue, May 18, 2010 at 3:43 PM, "Martin v. Löwis" wrote:
> So please join us in considering the issue fixed unless you can provide
> a really world example that demonstrates the contrary.
The server software I maintain (openrpg) experiences this issue with
when I tried porting the server code to
On Wed, May 19, 2010 at 4:17 PM, Peter Portante
wrote:
> Does anybody think that by having problems with the new GIL that it might
> further weaken the adoption rate for 3k? -peter
Nope, because the remaining issues with the new GIL affect the old GIL
as well, and have yet to be proven to affect
On Fri, May 21, 2010 at 8:26 AM, Brian Quinlan wrote:
> Except that now isn't the time for that discussion. This PEP has discussed
> on-and-off for several months on both stdlib-sig and python-dev.
I think any time till the PEP is accepted is a good time to discuss
changes to the API
Issues wit
On Wed, Sep 29, 2010 at 9:36 AM, M.-A. Lemburg wrote:
> You don't need to spend any extra time on this: just put all the tags
> that Dirkjan wants to delete into some other place. The separation
> work has already been done by Dirkjan.
>
> Note that the reason for keeping this history around is ju
On Thu, Jan 6, 2011 at 1:00 AM, Terry Reedy wrote:
> On 1/5/2011 8:59 PM, Nick Coghlan wrote:
> Run 3: -x test_capi test_concurrent_futures
> Instead of the normal output I expected, I got some of the craziest stuff I
> have ever seen. Things like
> "
> assert main_name not in sys.modules, main
On Tue, Jan 25, 2011 at 5:43 PM, M.-A. Lemburg wrote:
> I also don't see how this could save a lot of memory. As an example
> take a French text with say 10mio code points. This would end up
> appearing in memory as 3 copies on Windows: one copy stored as UCS2 (20MB),
> one as Latin-1 (10MB) and o
Google Code search limited to python
latin1: 3,489
http://www.google.com/codesearch?hl=en&lr=&q=latin1+lang%3Apython&sbtn=Search
latin-1: 5,604
http://www.google.com/codesearch?hl=en&lr=&q=latin-1+lang%3Apython&sbtn=Search
utf8: 25,341
http://www.google.com/codesearch?hl=en&lr=&q=utf8+lang%3Ap
On Sat, Feb 26, 2011 at 3:09 PM, Brett Cannon wrote:
> Hg's is the mq (Mercurial Queue) extension.
I prefer the hg shelve plugin
(http://mercurial.selenic.com/wiki/ShelveExtension) for this, more
intuitive to me
___
Python-Dev mailing list
Python-Dev@py
So reading the thread about the conversion and the dev guide at
http://potrou.net/hgdevguide/ there seems to not be a list of
recommended extensions that the python devs should have and use, only
a few examples of their use. so I figured I would build up a list for
other people to add to / comment
On Sat, Feb 26, 2011 at 6:19 PM, Éric Araujo wrote:
>> transplant
>> http://mercurial.selenic.com/wiki/TransplantExtension
>> required to port patches between major versions
> That’s actually not clear in the current PEP / devguide.
http://potrou.net/hgdevguide/committing.html#
On Sat, Mar 5, 2011 at 9:33 PM, Mark Hammond wrote:
> IIUC, the PEP language is referring to links which point to a specific
> version of Python and that there is no suggestion a 'python3' will live in
> the Python 3 binary tree. If that is correct and assuming we don't want to
> investigate usin
On Sun, Mar 6, 2011 at 7:52 AM, Stefan Krah wrote:
> It does here after a fresh clone:
Thats because it never got the revision that closed that branch, just
merge http://hg.python.org/cpython/rev/b77918288f7d to
http://hg.python.org/features/py3k-cdecimal/
On Sun, Mar 6, 2011 at 8:10 AM, Mark Hammond wrote:
> That sounds like a reasonable scheme people may choose to use - however, it
> doesn't really address the basic issue - something still needs to add
> c:\Python to PATH, and the scheme itself doesn't really necessitate the
> common parent direct
On Sat, Mar 19, 2011 at 4:44 AM, Glenn Linderman wrote:
> The launcher could be simpler if the Python installer placed versioned
> Python executables on the PATH. Unfortunately, historically it hasn't. If
> it did, would, or the launcher installer would place them there for
> pre-existing versio
On Sun, Mar 20, 2011 at 5:37 AM, "Martin v. Löwis" wrote:
> I see three problems with creating child processes:
> - WaitForSingleObject and GetExitProcessCode must work correctly. I
> think this is possible to achieve
> - applications using the debug API, PSAPI, etc. will be confused if
> the ac
On Sun, Mar 20, 2011 at 1:56 PM, "Martin v. Löwis" wrote:
> So if somebody would launch a python script with py.exe, they would
> think it was completed even though it would still be running.
Yes py.exe exits way before the python script, but the console stays
open, though now that I test it by r
On Wed, Mar 23, 2011 at 8:14 PM, Mark Hammond wrote:
> If you guys (or anyone) would like to agree on some precise rules for both
> the location of the config file and its contents and express this as a patch
> to the PEP text, I have no problem supporting it in the implementations.
> I'd like to
How about something like
http://andurin.com/python-issue-tracker/issue5863.htm but with proper
click to expand js not css hover expansion since the pure css solution
gets a little jumpy.
Dj Gilcrease
( | \ o () | o
I was wondering if there was a place I could get the modifications
that have been made at hg.python.org to add the Server Side Clone to
the hgweb interface.
Dj Gilcrease
( | \ o () | o
On Mon, Jul 4, 2011 at 2:27 AM, Mark Hammond wrote:
> While that makes alot of sense, the fact we are already "broken" in exactly
> the same way means I hope we can treat the restoration of associations as a
> separate issue - a worthwhile one, but not a pre-requisite for this PEP
> being approved
a Mercurial "super client" http://blog.red-bean.com/sussman/?p=116
Figured I would link to this for the people doing the HG investigation
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
In the thread about replacing re with regex someone mentioned adding
to __future__ which isnt a great idea as future APIs are already
solidified, they just live there to give developer time to adapt their
code. The idea of a __experimental__ area is good for any pep's or
stliib additions that are s
47 matches
Mail list logo
