On Tue, Feb 17, 2009 at 7:49 PM, "Martin v. Löwis" wrote:
> Can you please upload it to Rietveld also?
Will do. I'm getting a "500 Server Error" at the moment, but I'll keep trying.
Mark
___
Python-Dev mailin
On Tue, Feb 17, 2009 at 8:42 PM, Guido van Rossum wrote:
> Use the upload.py script (/static/upload.py) rather than the Create Issue
> page.
Thanks. That worked.
http://codereview.appspot.com/14105
___
Python-Dev mailing list
Python-Dev@python.org
ht
7;bzr pull' for the py3k branch:
Macintosh-3:py3k dickinsm$ bzr pull
Using saved parent location: http://code.python.org/python/py3k/
No revisions to pull.
...which is a bit surprising, since my last 'bzr pull' was a while ago.
Do I need to update something somewhere?
I
On Fri, Feb 27, 2009 at 7:26 PM, Barry Warsaw wrote:
> On Feb 25, 2009, at 2:03 PM, Mark Dickinson wrote:
>> Is the cron job that's supposed to update the bzr repository still
>> running?
> I think I have this fixed now. The branch updater is running on dinsdale
&
lable, and (b) was high
on my google search list
http://msdn.microsoft.com/en-us/magazine/cc163388.aspx
http://msdn.microsoft.com/en-us/library/aa363764(VS.85).aspx
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.or
thon 3 features for example.)
I know that you can use the -c option, but that only works at startup,
not every time you Restart Shell.
[snip]
--
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy
"Rapid GUI Programming with Python and Qt"
ll in PyLong_AsSsize_t
make any noticeable difference to these timings?
Mark
___
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%40mail-archive.com
On Tue, Mar 24, 2009 at 3:50 PM, Daniel Stutzbach
wrote:
> On Tue, Mar 24, 2009 at 10:13 AM, Mark Dickinson wrote:
>> Does removing the PyLong_Check call in PyLong_AsSsize_t
>> make any noticeable difference to these timings?
>
> Making no other changes from the trunk, remo
er
way or on other platforms.
* distutils already has the ability to create Windows installer
executables for pure-python apps/libs. I agree it would be nice if it
was an MSI but that is an implementation detail rather than
implementation requirement. How were Mike&#x
rom Python via the msvcrt module.
This would enable the test suite to disable assertions for its entire run.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
to
actually change the flags, just offers the ability for them to do so.
Curt's suggestion of redirecting to a file is better still - I'll look
at tweaking my patch to also offer that capability...
Cheers,
Mark
___
Python-Dev mailing l
On 25/03/2009 7:58 PM, David Bolen wrote:
Mark Hammond writes:
The issue was that Python unconditionally changed the behaviour of the
CRT, not only during the test suite.
Hmm... I was more or less referring to the state of the py3k tree as
of, say, r57823 back in 2007.
I was referring to
I'm going to poke my contacts at Microsoft and ask them if there is a way to
disable popups like this for a process that runs unattended and/or is running
as a windows service.
There is, and Curt pointed out one strategy for achieving this without
losing the checks it provides...
> Curt's
I frequently have this situation:
try:
try:
raise Thing
except Thing, e:
# handle Thing exceptions
raise
except:
# handle all exceptions, including Thing
It would be much more readable if there were a way to recatch a named
exception with the generic (catch-all
tural fit - but regardless, py2exe is
struggling to maintain itself at the moment...
Cheers,
Mark
___
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
On 29/03/2009 1:41 AM, andrew cooke wrote:
Mark Hammond wrote:
On 28/03/2009 9:50 PM, andrew cooke wrote:
Tim Roberts wrote:
[...] IronPython has certainly shown that Python can be successfully
implemented in a JIT compiled VM in a performant way, but it has issues
running C extension
On 2009-03-25, Guilherme Polo wrote:
> On Tue, Mar 24, 2009 at 4:26 AM, Mark Summerfield
wrote:
> > On 2009-03-23, Guilherme Polo wrote:
> >> On Mon, Mar 23, 2009 at 5:39 PM, Terry Reedy wrote:
> >> > Guilherme Polo wrote:
> >> >> On Wed,
On 6/04/2009 12:13 AM, Dirkjan Ochtman wrote:
I have a stab at an author map at http://dirkjan.ochtman.nl/author-map.
Could use some review, but it seems like a good start.
Just to be clear, what input would you like on that map?
I'm listed twice:
mark.hammond = Mark Hammond
mha
enefit seems small.
Mark
___
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%40mail-archive.com
etter
written as 2.0**DBL_MANT_DIG (or something similar).
As Antoine reported, the constant-folding caused quite
a confusing bug report (issue #5593): the problem (when
we eventually tracked it down) was that the folded
constant was in a .pyc file, and so wasn't upd
r work, adding a .0
to floats formatted without an exponent, but leaving
the .0 out when the exponent is present.
Should the .0 always be added? Or is it required
only when it would be necessary to distinguish
a float string from an integer string?
My preference is for the latter (i.e., format(x, '<')
should behave in the same way as repr and str
in this respect). But I'm biased, not least because
the other behaviour would be a pain to implement.
Does anyone care?
This email is already too long. I'll stop now.
Mark
___
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%40mail-archive.com
gt;> foo = set([1, 65537])
>>> foo.pop()
1
>>> foo = set([65537, 1])
>>> foo.pop()
65537
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pytho
ttle for bytes as I believe the most common *actual* use of
json will be via things like the twitter and couch libraries - and may
even be a key bottleneck for such libraries - so people will not be
directly exposed to its interface...
Mark
Cheers,
Mark
_
0)
> AssertionError: 1 != 0
Are you on OS X? This looks like
http://bugs.python.org/issue4388
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/op
On Fri, Apr 10, 2009 at 2:31 PM, Barry Warsaw wrote:
> bugs.python.org is apparently down right now, but I set issue 5724 to
> release blocker for 2.6.2. This is waiting for input from Mark Dickinson,
> and it relates to test_cmath failing on Solaris 10.
I'd prefer to leave this a
re a design choice which best supports
actual use. So to my mind the only real question is whether the above
*is* true, or if there are common use-cases which don't involve
utf8-off/on-the-wire...
Cheers,
Mark
___
Python-Dev mailing list
Pytho
On Tue, Apr 14, 2009 at 9:45 AM, Ned Deily wrote:
> Ned Deily wrote:
>> Eric Smith wrote:
>> > Before then, if anyone could build and test the py3k-short-float-repr
>> > branch on any of the following machines, that would be great:
>> >
>> [...]
>> > Something bigendian, like a G4 Mac
>>
>> I'
By the way, a simple native build on OS X 10.4/PPC passed all tests (that
we're already failing before).
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pytho
On Tue, Apr 14, 2009 at 11:37 AM, Mark Dickinson wrote:
> By the way, a simple native build on OS X 10.4/PPC passed all tests (that
> we're already failing before).
s/we're/weren't
___
Python-Dev mailing list
Pytho
no
I was expecting a "... universal" instead of "... no".
>From reading the autoconf manual, it seems as though AC_C_BIGENDIAN
knows some magic to make things work for universal builds; it ought to be
possible to imitate that magic somehow.
Mark
__
ld of Python,
one has to first regenerate configure and pyconfig.h.in using autoconf
version >= 2.62? If not, then I don't understand how the
AC_C_BIGENDIAN autoconf macro can be giving the right results.
Mark
___
Python-Dev mailing list
Python-D
on 32-bit PPC, 32-bit Intel and 64-bit Intel.
Mark
___
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%40mail-archive.com
On Tue, Apr 14, 2009 at 5:49 PM, Antoine Pitrou wrote:
> Mark Dickinson gmail.com> writes:
>> Do you know the right way to create a universal build?
>
> Not at all, sorry.
No problem :). I might try asking on the pythonmac-sig list.
Mark
sing piece of the puzzle. I think I
understand how to make things work now.
Mark
___
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%40mail-archive.com
/SDKs/MacOSX10.4u.sdk
> --with-universal-archs='32-bit' --with-computed-gotos OPT='-g -O3'
Great---thank you! And thank you for all the testing.
I'll try to sort all this out later this evening (GMT+1); I think I
understand how to fix everything now.
Mark
_
27;), Decimal('-NaN456')
>>> x + y
Decimal('NaN123')
>>> y + x
Decimal('-NaN456')
Similar effects can happen with regular IEEE 754 binary doubles,
but Python doesn't expose NaN payloads or signs, so we don't
see those effects witihin Pyth
On Fri, Apr 24, 2009 at 9:25 PM, Terry Reedy wrote:
> In going through this, I notice a lot of effort by Mark Dickenson and others
Many others, but Eric Smith's name needs to be in big lights here.
There's no way the short float repr would have been ready for 3.1 if
Eric hadn't
his is just about consistency, ease of implementation,
and aesthetics. As far as I can tell, the extra '.0' in the float
repr serves two closely-related purposes: it makes it clear to
the human reader that the number is a float rather than an
integer, and it makes sure that e.g., eval(rep
ID Flg off TTL Pro cks Src Dst
4 5 00 5400 77e1 0 3a 01 603d 192.168.1.2 88.198.142.26
Various others on #python-dev have confirmed that it's not working for them.
Does anyone know what the problem is?
Mark
___
Python-Dev ma
On Sun, Apr 26, 2009 at 4:19 PM, Aahz wrote:
> On Sun, Apr 26, 2009, Mark Dickinson wrote:
>>
>> The bugs.python.org site seems to be down.
>
> Dunno -- forwarded to the people who can do something about it. (There's
> a migration to a new mailserver going on, but I
On Sun, Apr 26, 2009 at 5:59 PM, Eric Smith wrote:
> Mark Dickinson wrote:
>> I propose changing the complex str and repr to behave like the
>> float version. That is, repr(4. + 10.j) should be "(4.0 + 10.0j)"
>> rather than "(4+10j)".
>
> I
rather than decimal. For example:
>>> int(1e308)
11097906362944045541740492309677311846336810682903157585404911491537163328978494688899061249669721172515611590283743140088328307009198146046031271664502933027185697489699588559043338384466165001178426897626212945177628091195786707458122783970171784415105291802893207873272974885715430223118336
Mark
___
Python-Dev mailing list
Pyt
e might not easily be able to distinguish
> between a significant trailing zero and fictitous bits.
As of 3.1, the printing code should be fine: it's using David
Gay's 'perfect rounding' code, so what's displayed should
be correctly rounded to the requested p
doubt that there's been
enough uptake of 'format' yet for this to risk significant breakage. So
unless there are objections I'll plan to make this change before this
weekend's beta.
Mark
___
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%40mail-archive.com
Larry Hastings wrote:
Counting the votes for http://bugs.python.org/issue5799 :
+1 from Mark Hammond (via private mail)
+1 from Paul Moore (via the tracker)
+1 from Tim Golden (in Python-ideas, though what he literally said
was "I'm up for it")
+1 from Michael F
r signatures would have to change.)
"""
Still, binary compatibility seems like a fairly strong reason not to
remove the closure field.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscri
ile: they'll segfault, or otherwise behave
unpredictably.
If that's not considered a problem, then surely we ought to be getting rid of
tp_reserved?
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
On Mon, May 4, 2009 at 9:15 PM, Antoine Pitrou wrote:
> Mark Dickinson gmail.com> writes:
>>
>> I *think* that third party code that's recompiled for 3.1 and that
>> doesn't use the closure field will either just work, or will produce an
>> easily-fixe
Eric Smith wrote:
Mark: I've reviewed this and it looks okay to me.
Thanks Eric - I've now applied that patch. As you mentioned in a
followup to the bug:
| Thanks for looking at this, Mark. If we could only assign issues to
| Python 3.2 and 3.3 to change the pending deprecation
ity to use a versioned file
for per-repo rules is something I'd like too. I believe that if a few
Windows users got together and agreed on both semantics and
implementation we could get such an enhancement landed in the core of hg...
Cheers,
Mark
dification - it builds straight from the Debian package.
I've written a simple REPL to demonstrate Python running in the
browser. There are some screenshots on my blog [3]. I haven't
implemented accessing the DOM from Python yet - that's another project
for later. :-)
Mark
[1]
read_fd, write_fd = os.pipe()
return os.fdopen(read_fd, "r"), os.fdopen(write_fd, "w")
Mark
___
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%40mail-archive.com
Cameron Simpson wrote:
> On 14Jun2009 16:42, Mark Seaborn wrote:
> | I use a convenience function like this, so that GC takes care of the FDs:
> |
> | def make_pipe():
> | read_fd, write_fd = os.pipe()
> | return os.fdopen(read_fd, "r"), os.fdopen(write_fd,
place to prevent editors on Windows
'accidently' mixing eol styles? If so, this cycles back to the first
question - how would we know which files get treated that way?
Thanks,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
On 3/07/2009 9:28 PM, Dirkjan Ochtman wrote:
On Fri, Jul 3, 2009 at 01:01, Mark Hammond wrote:
Although this has come up in the past, I don't recall a resolution.
What is your plan to handle svn:eol-style? We have some files in the tree
which need that support and it isn't c
la hg
repo for exactly this reason.
Cheers,
Mark
___
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%40mail-archive.com
On 3/07/2009 11:43 PM, Dirkjan Ochtman wrote:
On Fri, Jul 3, 2009 at 15:31, Mark Hammond wrote:
So we must work without effective EOL support? I fear we will end up like
the mozilla hg repo with some files in windows line endings and some with
linux. While my editing tools are good enough to
el free to enlighten me!
In that case, and given that I expect more Windows users to be clueless
about EOL issues than users of other operating systems, I propose we
check in all files initially with Windows line endings
Mark
___
Python-Dev mailing l
e hg core dev team. Patches or comments regarding
win32text are always met with "but no one here ever uses it". If they
did, and some of the core hg team tried to experiment with win32text and
mixed line ending repos the problems would, I believe, become
self-evident...
Cheers,
M
en to use their native line ending (sauce for the goose is
sauce for the gander, and all that...)
* commit hooks be implemented to enforce this - but this should not be
necessary if the above was implemented and socially enforced.
Cheers,
Mark
Cheers,
Nick.
[1] h
Sorry Dirkjan - I just noticed I didn't CC you on this mail originally.
I'm wondering if you have any more thoughts on these EOL issues and if
there is anything I can do to help?
Cheers,
Mark
On 4/07/2009 2:03 PM, Mark Hammond wrote:
On 4/07/2009 12:30 PM, Nick Coghlan wrote:
..
seless and taking reviewer's time for nothing ?
>
> Please advise, if this is deemed useful, I'll continue further
I think this is valuable work---please do continue!
Just out of interest, how many false positives did you have
to filter out in finding the 5 cases above?
Mark
_
hing there of
interest that isn't already in trunk and py3k. It was merged to
trunk in r62380.
--
Mark
___
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%40mail-archive.com
32text 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 place which offers a full solution and the
hg developers are committed to it, I promise I'll put my hand up to help
with implementation i
On 5/08/2009 3:56 PM, Ben Finney wrote:
Mark Hammond writes:
Let's say I make a branch of the hg repo, myself and a few others work
on it committing as we go, then attempt to merge back upstream. Let's
say some of the early commits on that clone introduced "bad" line
end
On 5/08/2009 4:50 PM, Ben Finney wrote:
Mark Hammond writes:
On 5/08/2009 3:56 PM, Ben Finney wrote:
Mark Hammond writes:
Let's say I make a branch of the hg repo, myself and a few others work
on it committing as we go, then attempt to merge back upstream. Let's
say some of
ion I see is a truly cross-platform extension to implement these
rules which every Python committer, regardless of operating-system, is
expected to use - but that doesn't seem the consensus.
As mentioned, I'm willing to lend manpower for this once there
On 5/08/2009 6:00 PM, Ben Finney wrote:
Mark Hammond writes:
As already mentioned in this thread, a capability similar to what svn
or cvs offers would be sufficient.
That capability presented by centralised VCSen is entirely dependent on
the fact that they *are* centralised. Using a
On 5/08/2009 6:25 PM, Dirkjan Ochtman wrote:
On Wed, Aug 5, 2009 at 01:43, Mark Hammond wrote:
Thanks Nick; I didn't want to be the only one saying that. There is a fine
line between asserting reasonable requirements for Windows users and being
obstructionist and unhelpful, and I'm
e shared by the community and therefore addressed as a
community, thereby ensuring all platforms are considered as important as
any other.
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
VS hook would be an alternative
approach? (I can't imagine such a hook would be an *easier* approach,
I only mention it because it makes it clearer where the issue lies).
I must concede that Windows developers are the minority here - but
assuming we want a le
itors, and as mentioned, am
personally responsible for accidentally checking in \r\n files into what
should be a \n repo. I am slowly and painfully learning to be more
careful - IMO, I shouldn't need to...
Cheers,
Mark
___
Python-Dev mailing l
On 5/08/2009 9:28 PM, Dirkjan Ochtman wrote:
On Wed, Aug 5, 2009 at 13:19, Mark Hammond wrote:
Configuring on each clone would certainly be sub-optimal, so the proposal is
this configuration be stored in a versioned file in the repo.
Even if we do that, enabling hg extensions will still need
On 6/08/2009 12:28 AM, Stephen J. Turnbull wrote:
Mark Hammond writes:
> I'm not sure what point you are trying to make, but I believe it *is*
> possible for a solution to be found here which will keep Windows users
> happy. I'm guessing you haven't had much p
ber generated).
[1] http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/CODES/mt19937ar.c
Mark
___
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%40mail-archive.com
nt item here is currently the win32text stuff.
Mark Hammond said he would work on this; Mark, when do you have time
for this? Then I could set apart some time for it as well.
I can make time, somewhat spasmodically, starting fairly soon. Might I
suggest that as a first task I can resurrect my old stale
[Adjusted the CCs...]
On 19/08/2009 8:21 AM, Dj Gilcrease wrote:
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
ou be willing to start a thread with the hg developers about this
issue? If something like this can't get into the core, I will drop any
expectations of it becoming a viable general solution for windows
focused projects, so would limit the work I am willing to invest to the
commitm
On 22/08/2009 12:10 AM, Dj Gilcrease wrote:
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
On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote:
Mark Hammond writes:
> Something like ~/.hgrules having:
Surely you mean $PROJECTROOT/.hgrules?
Indeed.
> [config] # or maybe [rules] ?
> required_extensions = win32text, some_pydev_specific_extension
[e
On 22/08/2009 6:52 PM, Stephen J. Turnbull wrote:
Mark Hammond writes:
> On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote:
> Possibly - although I would expect the existing section names be reused
> when applied to a versioned file, I'd be more than happy for the h
d - instead
another extension with different semantics (ie, no guessing based on
file content) should be used, and enforced, instead.
Or have I misunderstood?
Assuming I am correct, I am inclined to agree - win32text may be "good
enough" in the short term, but it is f
vailable by the time a decision is made to migrate. If code is
available, then migration will happen (no matter whether the code
has an owner); if no code is available, migration will stall.
Right - I guess we are all still struggling with exactly what "
nt item here is currently the win32text stuff.
Mark Hammond said he would work on this; Mark, when do you have time
for this? Then I could set apart some time for it as well.
Have stalled a bit on the fine-grained branch processing, hope to move
that forward tomorrow.
I'm afraid I've also s
On 30/08/2009 9:37 PM, Martin Geisler wrote:
Mark Hammond writes:
1) I've stalled on the 'none:' patch I promised to resurrect. While
doing this, I re-discovered that the tests for win32text appear to
check win32 line endings are used by win32text on *all* platforms, not
ju
e changed, though. It
currently left-aligns by default (my fault: I just blindly followed PEP 3101
without thinking too hard about it). I'd like to fix this for 3.2 and 2.7; I'm
not sure whether it's too disruptive to fix it in 3.1 and 2.6.
Mark
__
and the entire
test-suite still runs without errors.
In 2.x, it's possible that this call is necessary for some bizarre
combinations of __cmp__ and __eq__; I haven't tried to get my head
around this yet.
I'll open an issue for the duplicate __eq__ calls.
Mark
___
On Tue, Sep 22, 2009 at 4:12 PM, Mark Dickinson wrote:
> I'll open an issue for the duplicate __eq__ calls.
http://bugs.python.org/issue6970
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
On Wed, Sep 23, 2009 at 9:12 AM, Chris Withers wrote:
> Mark Dickinson wrote:
>>
>> I (still :-) think this is covered, for Python 2.x at least, by:
>>
>> http://docs.python.org/reference/datamodel.html#coercion-rules
>
> But this isn't coercion! :-)
Agree
gt; that purpose, but it seems like it would be helpful if this sort of
> "validation suite" was maintained as a separate project all implementations
> could use and contribute to.
+1
Mark
___
Python-Dev mailing list
Python-Dev@python.org
ncluded in the standard install
> in the tests directory.
How big is big? For comparison, CPython's Lib/test/decimaltestdata
directory alone is already over 4Mb, so maybe size isn't an issue?
Mark
___
Python-Dev mailing list
Python-Dev@py
r
the cmath module is included in the core Python executable.
Cluelessly yours,
Mark
___
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%40mail-archive.com
On Sun, Sep 27, 2009 at 8:48 AM, Brett Cannon wrote:
> On Sun, Sep 27, 2009 at 00:21, Mark Dickinson wrote:
[...]
>> So I've now got a file Modules/math_support.c that contains
>> some functions needed by both mathmodule.c and
>> cmathmodule.c, as well as a couple of f
1')
>> >>> y.ip
>> IPv4Address('192.168.1.0')
>
> With those semantics, IPv4Network objects with distinct IP addresses (but
> the same network) could no longer be stored in a dictionary or set. IMO, it
> is a little counter-intuitive for obj
review.appspot.com/124057 still allows the networks to be
> included in a set or as a dict key
>
>>>> net1 = IPNetwork("10.1.2.3/24")
>>>> net2 = IPNetwork("10.1.2.0/24")
>>>> print hash(net1) == hash(net2)
> False
>>>>
elation for
determining container membership. Mostly these two different meanings
get along fine, though they lead to some fun when trying to ensure
that x == y implies hash(x) == hash(y) for x and y two different numeric
types.
But since Decimals and floats aren't used as set elements
On Wed, Sep 30, 2009 at 10:52 AM, Paul Moore wrote:
> 2009/9/30 Mark Dickinson :
>> Please could someone who understands the uses of IPNetwork better than
>> I do explain why the following wouldn't be a significant problem, if __eq__
>> and __hash__ were modified to disr
On Wed, Sep 30, 2009 at 12:06 PM, Nick Coghlan wrote:
> Mark Dickinson wrote:
>> Okay, so maybe this is an abuse of IPv4Network. But I'd (mis?)understood
>> that the retention of the .ip attribute was precisely a convenience to allow
>> this sort of use. If not, then
logging.Formatter(fmt="{asctime} - {name}")
> If %-formatting is to be deprecated, the transition strategy here
> is trivial. However, no one has yet written translators, and it is
> not clear what heuristics should be used, e.g. should the method
> just try %-fo
the work in to do the
backport.
Masochists who are still reading by this point and who want more
information about the new repr implementation can see the issue
discussion:
http://bugs.python.org/issue1580
Thoughts?
Mark
___
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%40mail-archive.com
501 - 600 of 1370 matches
Mail list logo
