Christian Tismer stackless.com> writes:
>
> Despite the fact that Python probably has to be changed:
> If it is true then all the 32-bit Linux Pythons have a 12
> byte GC head, IOW they are *all* badly aligned.
Why are they badly aligned?
The fact that long double is 12 bytes long doesn't mean i
Christian Tismer stackless.com> writes:
>
> The point is: The GC header is a structure invisible to the "real"
> gc allocated objects. It is opaquely prepended to every gc aware
> object. Therefore, it *needs* to have the correct size, in order
> to propagate its (already correct) alignment to th
Antoine Pitrou pitrou.net> writes:
>
> In any case, you seem to be right on this particular point: the PyGC_Head
> union
> should probably contain a "double" alternative in addition to the "long
> double"
> (and perhaps even a "long long&quo
Christian Tismer stackless.com> writes:
>
> Well, I doubt that a 12 byte long double causes any other
> alignment but 4.
In 32-bit mode, no. But under x86-64 Linux, a long double is 16 bytes (!!).
Regards
Antoine.
___
Python-Dev mailing list
Python
Roumen Petrov roumenpetrov.info> writes:
>
> Antoine Pitrou wrote:
> >
> > In 32-bit mode, no. But under x86-64 Linux, a long double is 16 bytes (!!).
>
> And alignment is ?
16 bytes as well.
___
Python-Dev mailing list
Antoine Pitrou pitrou.net> writes:
>
> Roumen Petrov roumenpetrov.info> writes:
> >
> > Antoine Pitrou wrote:
> > >
> > > In 32-bit mode, no. But under x86-64 Linux, a long double is 16 bytes
> > > (!!).
> >
> > And alignment i
Brett Cannon python.org> writes:
> > Oh, I don't know. All this new-fangled technology... Can't you just
> > leave it in your workspace, unsubmitted, until you get to fixing it?
>
> Oh sure, I normally just leave it in my scratch svn checkout until I get
around to it.
What? You're not even usin
Martin v. Löwis v.loewis.de> writes:
>
> > In addition to that union, we should also have a particular mechanism to
compute
> > what the proper offset should be between the PyGC_Head and the PyObject.
>
> Why is that difficult? It's sizeof(PyGC_Head).
Is it enough to correctly propagate the al
Neil Hodgson gmail.com> writes:
>
> typedef union _gc_head {
>struct {
>union _gc_head *gc_next;
>union _gc_head *gc_prev;
>Py_ssize_t gc_refs;
>} gc;
>long double dummy; /* force worst-case alignment */
>double dumm
Antoine Pitrou pitrou.net> writes:
>
> We could add a PY_LONG_LONG to the mix just in case.
> By the way, will this kind of thing be frozen by the PEP ABI?
(I meant the ABI PEP, sorry)
___
Python-Dev mailing list
Python-Dev@pyt
Jesse Noller gmail.com> writes:
>
> I really do think this mail thread needs to move to disutils-sig or
> python-ideas.
+1
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.
Hello Dirkjan,
Dirkjan Ochtman ochtman.nl> writes:
>
> +As an optional optimization technique, I have performed a reordering pass on
> +the revlogs (internal Mercurial files) resulting from the conversion. In some
> +cases this results in dramatic decreases in on-disk repository size.
Can you
Oleg Broytmann phd.pp.ru> writes:
>
>These files are in 8859-1 encoding (names in comments, at least):
> http://svn.python.org/view/python/trunk/Lib/encodings/punycode.py
> http://svn.python.org/view/python/trunk/Lib/test/test_csv.py
> http://svn.python.org/view/python/trunk/Tools/i18n/msgfmt
Martin v. Löwis v.loewis.de> writes:
>
> No, it's not. PEP 8 mandates that non-ASCII code in the Python source
> code is in Latin-1.
Ok, point taken.
Having several encodings (and several indentation rules) certainly makes things
more annoying for contributors than they should, however.
Regards
M.-A. Lemburg egenix.com> writes:
>
> Please file a bug report for this. f.readlines() (or rather
> the io layer) should be using Py_UNICODE_ISLINEBREAK(ch)
> for detecting line break characters.
Actually, no. It has been designed from the start to only recognize the
"standard" line break repres
M.-A. Lemburg egenix.com> writes:
>
> What I don't understand is why the io layer tries to reinvent
> the wheel here instead of just using the codec's .readline()
> method - which *does* use .splitlines() and has full support
> for all Unicode line break characters (including the CRLF
> combinati
Raymond Hettinger rcn.com> writes:
>
> For example:
>
>x = min(seq) except ValueError else 0 # default to zero for empty
sequences
How about:
x = min(seq) if seq else 0
Shorter and more readable ("except X else Y" isn't very logical).
> sample_std_deviation = sqrt(sum(x - mu for
M.-A. Lemburg egenix.com> writes:
>
> Sure, but the code for line splitting is not really all that
> complicated (see PyUnicode_Splitlines()), so could easily
> be adapted to work on buffers directly.
Certainly indeed. It all comes down to compatibility with the original
implementation.
(PEP 311
M.-A. Lemburg egenix.com> writes:
>
> IMHO, it would be a lot better to add full Unicode support
> for line breaks to the io layer. Given that the code for the
> complicated handling of the CRLF combination is already there,
> it's not difficult to add support for the remaing line break
> charact
Jim Jewett gmail.com> writes:
>
> In python 3, why does codecs.open even still exist?
I don't remember anyone proposing to deprecate it, so I suppose that's the
(social) reason.
> So at this point, are there any differences beyond:
(c) The built-in open is probably a little more featureful, es
Benjamin Peterson python.org> writes:
>
> Once Subversion is back up (today, tomorrow?), I will tag the 3.1
> maintence branch as 3.1.1rc1. The tree will remain frozen until
> Saturday. If at that time, no one has found something wrong with the
> RC, I will retag it as the final bugfix release.
Chris Withers simplistix.co.uk> writes:
>
> However, I'm kinda stumped on where to start with debugging the
> difference. I've tried upping the buffer size as suggested in the issue,
> but it's had no effect...
Then perhaps it's not the same bug.
Please take a look at CPU utilization during th
Stefan Behnel behnel.de> writes:
>
> IMHO, that's pretty far from obvious when you look at the code.
A "yield" wrapped in a list comprehension looks far from obvious IMO anyway,
whether in 2.x or 3.x. It's this kind of "smart" writing tricks people find that
only makes code more difficult to rea
Chris Withers simplistix.co.uk> writes:
>
> Well, it's locked at 25% on a quad core box, so yeah, I'd say something
> is wrong
>
> I guess I could try profile it and finding out where most of the time is
> being spent?
I guess you could indeed :-)
Antoine.
Hello,
Jacob Rus gmail.com> writes:
>
> Okay, I made another patch,
>
> http://bugs.python.org/issue6626
>
> That adds some deprecation warnings to many of the functions/methods
> in the module.
After a fair amount of discussion on Rietveld, I think you should post another
patch without the d
Jason R. Coombs jaraco.com> writes:
>
> I'm certain there are other, more obscure examples, but I feel these two use
cases demonstrate some fairly
> common potential use cases for something like a composition function.
I also think it would be a nice addition.
(but someone has to propose a patch
Raymond Hettinger rcn.com> writes:
>
> IMO, its only virtue is that people coming from functional languages
> are used to having compose. Otherwise, it's a YAGNI.
Then I wonder how partial() ended up in the stdlib. It seems hardly more
useful than compose().
Either we decide it is useful to hav
> PEP 309 was written, discussed, approved, and implemented - that's how
> partial ended up in the stdlib.
Ok, I'm surprised that a single addition to a module needed a PEP in
order to be approved.
Interestingly, here's what the summary section in PEP 309 says:
« A standard library module funct
Le lundi 17 août 2009 à 09:07 +0200, "Martin v. Löwis" a écrit :
> Ok, that's also what the patch has proposed. I was puzzled when I read
>
>l.sort(key=compose(itemgetter(1), itemgetter(0
>
> because I expected it to mean
>
>l.sort(key=lambda x:x[1][0])
But that's itemgetter's fault
Le lundi 17 août 2009 à 20:53 +1000, Nick Coghlan a écrit :
> P.S. PEP 309 is wrong when it says a C version probably isn't worthwhile
> - between the time the PEP was first implemented and the time 2.5 was
> actually released, enough investigation was done to show that the speed
> gain from Hye-Sh
Le Tue, 18 Aug 2009 13:00:06 -0700, Peter Moody a écrit :
> Howdy folks,
>
> I have a first draft of a PEP for including an IP address manipulation
> library in the python stdlib. It seems like there are a lot of really
> smart folks with some, ahem, strong ideas about what an IP address
> module
Le Wed, 19 Aug 2009 08:35:15 -0700, Peter Moody a écrit :
>>
>> does it mean that the objects are mutable? Would it make sense to make
>> them immutable and therefore hashable (such as, e.g., datetime
>> objects)?
>
> that's a good point. I'll implement __hash__ in the BaseIP class.
It is a commo
Eric Smith trueblade.com> writes:
>
> Is there some existing library that uses .number or .zero? IPy uses .net
> (and .broadcast for [-1]).
Why not be explicit? Use .first and .last.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
Guido van Rossum python.org> writes:
>
> Are you a lawyer? Do you know the legal history of Python
> distributions and the US export laws? It's not so easy -- for one, the
> PSF (a US foundation) owns the copyright.
Does it? As far as I understand, the contributor agreement is not a copyright
tr
DrKJam gmail.com> writes:
> netaddr employs a simple variant of the GoF Strategy design pattern (with
added Python sensibility).
It would be nice if you could avoid employing this kind of acronyms without
explaining them. Not everybody drinks the design pattern kool-aid.
(Google tells me that GoF
Martin v. Löwis v.loewis.de> writes:
> [...]
> Then, class IPAddress has a method reverse_dns, which is defined
> as
>
> def reverse_dns(self):
> """The reverse DNS lookup record for this IP address"""
> return self._module.int_to_arpa(self._value)
>
> So IPv4 addresses and I
Michael Foord voidspace.org.uk> writes:
>
> Really? Discussing the GoF design patterns by name seems to be prevalent
> amongst the programmers I know (yourself excluded of course...).
Ah? I still haven't understood what "Gang of Four" is supposed to be, however.
Is it a design pattern?
Besides
Brett Cannon python.org> writes:
>
> Now I can't change
> co_filename from Python as it's a read-only attribute and thus can't
> match this functionality in importlib w/o creating some custom code to
> allow me to specify the co_filename somewhere
Why can't we simply make co_filename a writable
Nick Coghlan gmail.com> writes:
>
> I thought of that question as well, but the later exchange between Guido
> and Brett made me realise that a lot more than the top level module code
> object is affected here - the adjustment also needs to be propagated to
> the code objects created by the modul
Benjamin Peterson python.org> writes:
>
> > Why can't we simply make co_filename a writable attribute instead of
inventing
> > some complicated API?
>
> Because code objects are supposed to be a immutable hashable object?
Right, but co_filename is used neither in tp_hash nor in tp_richcompare.
Brett Cannon python.org> writes:
>
> I will plan to take this approach then;
> http://bugs.python.org/issue6811 will track all of this. Since this is
> a 3.2 thing I am not going to rush to implement this.
I still don't understand what the point is of this complicated approach (adding
an argumen
Brett Cannon python.org> writes:
>
> I should also mention that I am +0 on the marshal.load* change. I
> could be convinced to try to pursue a mutable co_filenme direction,
> but considering the BDFL likes the marshal.load* approach and it opens
> up the possibility of compacting the marshal form
Gregory P. Smith krypto.org> writes:
>
> food for thought as noticed by a coworker who has been profiling some hot code
to optimize a library...If a function does not have a return statement we return
None. Ironically this makes the foo2 function below faster than the bar2
function at least as m
Gregory P. Smith krypto.org> writes:
>
> I was just wondering if a bytecode for a superinstruction of the common
sequence:
> 6 POP_TOP
> 7 LOAD_CONST 0 (None)
> 10 RETURN_VALUE
> might be worth it.
I think superinstructions in general would be a good thing to experiment, as
wpytho
Le mardi 01 septembre 2009 à 15:09 +0200, Xavier Morel a écrit :
> "We" are not Erlang, Smalltalk, OCaml or Haskell either, sadly.
Well, feel free to prefer an unreadable language if you want :)
Having implicit return values is certainly not something which follows
Python's design principles. Even
Simon Cross gmail.com> writes:
>
> Well, since the source for _read_chunked includes the comment
>
> # XXX This accumulates chunks by repeated string concatenation,
> # which is not efficient as the number or size of chunks gets big.
>
> you might gain some speed improvement wit
Chris Withers simplistix.co.uk> writes:
>
> The fix is applied on the trunk, but the problem still exists on the 2.6
> branch, 3.1 branch and 3.2 branch.
>
> Which of these should I merge to? I assume all of them?
The performance problem is sufficiently serious that it should be considered a
b
Guido van Rossum python.org> writes:
>
> +1 on trying this. Constructing a 116MB string by concatenating 1KB
> buffers surely must take forever. (116MB divided by 85125 recv() calls
> give 1365 byte per chunk, which is awful.)
It certainly is quite small but perhaps the server tries to stay belo
Mark Hammond gmail.com> writes:
>
> What is the hope of an EOL extension which meets our requirements coming
> directly out of the hg community? If that hope is small, where does
> that leave us?
I'm starting to wonder what the problem really is that makes it so
Python-specific. If I understo
Le samedi 05 septembre 2009 à 15:19 +0200, "Martin v. Löwis" a écrit :
> No. It's about files that must, when checked out on Windows, have CRLF
> endings, and, when checked out on Unix, have LF endings - i.e. all the
> ..py, .c, .h, and .rst files, plus a couple of others which don't require
> spec
Terry Reedy udel.edu> writes:
>
> If essentially all text files need fixed line endings on Windows, then
> hg really needs this built in. Has it really not been used much on Windows?
Mercurial is used by e.g. Mozilla, which is not really known for poor Windows
support (chances are many Firefox
Brett Cannon python.org> writes:
>
> On Fri, Sep 11, 2009 at 00:51, R. web.de> wrote:
> > How to adapt the existing M.L.S. from Compilermessages to
> > Core-Compiler-Words.
> >
> > Where to begin, for implemantation of this feature?
>
> Um, what existing multi-language support? CPython doesn't
Andrew McNamara object-craft.com.au> writes:
>
> >>> ipaddr.IPv4Network('192.168.1.1/16').network
> IPv4Address('192.168.0.0')
Er, does this mean that taking the `network` attribute from a network object
actually gives an address object (not a network)?
It looks horribly misleading to me
Scott Dial scottdial.com> writes:
>
> >>> gateway = net[1]
>
> I was then confused, because:
>
> >>> print(type(gateway))
>
>
> Which sorta blew my mind.. I fully expected to receive an IPNetwork back
> from that operation.
Speaking as a non-network specialist, it actually looks logical to m
Hello,
I would like to know if your approach is based on Python 2.x or 3.x.
Python 3.x has new API provisions, in the I/O layer, for non-blocking I/O
and it would be nice if your work could fit in that framework.
> >Popen can be made to act like a file by simply
> >using the methods att
R. David Murray bitdance.com> writes:
>
> x = IPv4AddressWithMask('192.168.1.1/24')
> x.network == IPv4Network('192.168.1.0/24')
> x.network[1] == x
I don't think we need an IPAddressWithMask which would just complicate the API
without any obvious benefit.
We just need a factory f
R. David Murray bitdance.com> writes:
>
> I would find that acceptable but sub-optimal. Most of my use cases
> (which involve manipulating router and firewall configuration files) would
> then start by making a little class named AddressWithNetwork to hold the
> tuple returned by your parse func
Le mardi 15 septembre 2009 à 15:48 -0400, R. David Murray a écrit :
>
> It's useful functionality is parsing/validating an address+mask, rendering
> as address+mask, and being able to get the associated IP and network objects
> from it. It's a small class, but useful, IMO.
If it's only about par
Peter Moody hda3.com> writes:
>
> However, I do not think
> that the proposed API should accept, eg, IPv4Network('192.168.1.1/24')
> as valid. That's just too confusing and error prone.
> >>>
> >>> Indeed, it should throw some kind of ValueError instead.
> >>
> >> Peter, what do y
Antoine Pitrou pitrou.net> writes:
>
> I don't see any valid reason for entering a network as "192.168.1.1/24" rather
> than the canonical "192.168.1.0/24". The former might indicate a typing error
> or
> a mental slip, so let's be helpful and si
Stephen J. Turnbull xemacs.org> writes:
>
> Rather, don't you want to just give IPv4Address an attribute
> 'network'? This could then be filled in by the indexing method on
> IPv4Network.
It doesn't make sense to me. An address, conceptually, doesn't have a "network".
If I say "213.5.4.68", it
Michael Foord voidspace.org.uk> writes:
>
> Given the long discussion on the stdlib-sig it seems like a discussion
> of the standard library would be useful. Potential topics include (some
> of which partially overlap each other):
>
[snip]
Let me suggest the following additional point:
* Cla
Le Mon, 14 Sep 2009 09:44:12 -0700, Peter Moody a écrit :
> Folks, Guido,
>
> I believe PEP 3144 is ready for your review. When you get a chance, can
> you take a look/make a pronouncement?
Besides what has already been said in the thread, I have a bunch of
comments:
It should be noted
Peter Moody hda3.com> writes:
>
> the address with all of the hosts bits masked to zero is most commonly
> referred to as the network address. same as the address with all of
> the host bits set to one is called the broadcast address. calling it
> something like base_address or min_address will c
Le Thu, 17 Sep 2009 14:30:28 +1200, Greg Ewing a écrit :
>
> 3) an Address with an attached Network
>
> An Address could be constructed in three ways:
>
>Address(ip_number)
>
>Address(ip_number, network = )
>
>Address(ip_number, mask = )
> # constructs and attaches a suitably-
Le Mon, 14 Sep 2009 09:44:12 -0700, Peter Moody a écrit :
> Folks, Guido,
>
> I believe PEP 3144 is ready for your review. When you get a chance, can
> you take a look/make a pronouncement?
I might add that, according to the whole discussion, it seems not all of
the API is exposed in the PEP. W
DrKJam gmail.com> writes:
>
> BTW, has anyone considered use of the term *CIDR to refer to an address + mask
object?
This sounds too obscure for a non-specialist.
> Obviously we'd still have the issue of what to do with the host bits to the
right of the supplied mask (keep or discard). This is
Peter Moody hda3.com> writes:
>
> Again, the same error-catching functionality can be obtained through
> an option to the constructor. network and broadcast attributes can be
> renamed to .\1_address to alleviate confusion as well.
My remark was not targetting error-catching of non-zero low bits
Le Fri, 18 Sep 2009 21:17:29 +0200, Pascal Chambon a écrit :
Hello,
First, thanks for experimenting with this.
(as a sidenote, we lack real-world testing of non-blocking features,
perhaps you want to take a look)
> I'm currently working on a reimplementation of io.FileIO, which would
> allow
James Y Knight fuhm.net> writes:
>
> Why are you just making things up? There is a *vast* amount of
> precedent for how file operations should work. Python should follow
> that precedent and do like POSIX unless there's a compelling reason
> not to.
Actually, Python is cross-platform and t
Le Sat, 19 Sep 2009 09:19:53 +0900, Stephen J. Turnbull a écrit :
> Antoine Pitrou writes:
> > James Y Knight fuhm.net> writes:
> > >
> > > Why are you just making things up? There is a *vast* amount of
> > > precedent for how file operations should
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 Buffered* objects.
> If it's too late to modify t
Hello,
> *Truncate and file pointer semantics*
[snip]
The major problem here is that you are changing the current semantics.
I don't think the argument you are making for it is strong enough to
counter-balance the backwards compatibility issue. The situation would be
different if 3.0 hadn't be
Zooko O'Whielacronx gmail.com> writes:
>
> Users occasionally get binaries built for a
> compatible Linux and Python version but with a different UCS2-vs-UCS4 setting,
> and those users get mysterious memory corruption errors which are hard to
> diagnose.
What "binaries" are you talking about?
A
Le Sun, 20 Sep 2009 10:17:45 -0600, Zooko O'Whielacronx a écrit :
>
>> AFAIK, C extensions should fail loading when they have the wrong UCS2/4
>> setting.
>
> That would be an improvement! Unfortunately we instead get mysterious
> misbehavior of the module, e.g.:
>
> http://bugs.python.org/setu
Le Sun, 20 Sep 2009 10:33:23 -0600, Zooko O'Whielacronx a écrit :
>
> By the way, I was investigating this, and discovered an issue on the
> Mandriva tracker which suggests that they intend to switch to UCS4 in
> the next release in order to avoid compatibility problems like these.
Trying to use
Hello,
I realize I may have missed some kind of formal announcement, but why
have all the buildbots been down for a number of days (weeks?) now?
Thanks
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
Tarek Ziadé gmail.com> writes:
>
> [setup]
> name: Foo
> version: 1.2
I am probably missing something, but why doesn't it use the more common
ini-style:
[setup]
name = Foo
version = 1.2
Regards
Antoine.
___
Python-Dev maili
Brett Cannon python.org> writes:
>
> Trust me, if you are doing open source for
> anything other than altruistic reasons you are bound to be
> disappointed.
I'm surprised by this statement but perhaps it's a matter of vocabulary.
Having fun and doing things you like to do does not strike me as "
Benjamin Peterson python.org> writes:
>
> Hi everyone,
> I've started plotting the release of 2.7. I'd like to try for a final
> release mid next summer. 3.2 should be released, if not at the same
> time as 2.7, within a few weeks to avoid 2.x having features which 3.x
> doesn't. If no one has pr
Tarek Ziadé gmail.com> writes:
>
> Also, I am more concerned of not having enough end users involved in
> that process.
> End users would be: any python developer that needs
> to package his code, or any os packager that needs to package a python
> distribution
> for his system. But those are har
P.J. Eby telecommunity.com> writes:
>
> Hell, I *support* the bulk of Tarek's setup.cfg proposal, and don't
> even object to him Pronouncing it or cutting off the discussion! My
> only issue on Python-Dev was his inaccurate implication that it was a
> SIG consensus rather than a pronouncement
Benjamin Peterson python.org> writes:
>
> Different RMs would have different times they can do releases,
> so I would worry about there being a release in a slightly different
> stage of a different branch every couple weeks.
Assuming you can do it, +1 for you (Benjamin) being RM for both 2.7 an
Michael Foord voidspace.org.uk> writes:
>
> Are we definitely decided that 2.7 will be the last major release in the
> 2.x cycle?
I don't think any "definitive" decision was made, but judgeing by Benjamin's and
Brett's answers (and by my own sentiment :-)), it certainly is the expectation
of so
MRAB mrabarnett.plus.com> writes:
>
> It's called a 'subscript' because conventional mathematical notation
> uses subscripting. Newbies might be acquainted with the term 'index'
> from books, where the 'value' is non-numeric. It's a bit unfortunate
> that dicts have keys+value instead of index+va
P.J. Eby telecommunity.com> writes:
>
> I doubt that it was intentional on Tarek's part (checking the thread
> shows that Antoine's the one who first cut the cc: list), but the
> fact remains that I hadn't seen it when I sent my
> message.
Just FYI, there are two reasons that I cut the CC lis
Le Thu, 24 Sep 2009 00:23:31 -0400, David Lyon a écrit :
>
> Depends on where the machines are. There are good tools do check all
> automatically. Nagios is one.
>
> Anyway, this would suite my work schedule for the next 12 months.
>
> Do we already have the machines? or do they need to be acqui
R. David Murray bitdance.com> writes:
>
> And if Snakebite isn't enough I
> have a well-connected platform I could run Linux buildbots on in
> vserver virthosts, and a less-well-connected platform that could run
> KVM based stuff.
I suppose Snakebite will be enough, but only once it is ready :)
Peter Moody hda3.com> writes:
>
> To be explicit though, unless I'm drastically misreading what you're
> asking for, I consider the design you're proposing to be broken from a
> usability perspective (striving for academic/pedantic correctness over
> accepted practice).
It is certainly not acade
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 can
save it first and restore i
Le Sun, 27 Sep 2009 10:20:23 +0200, Pascal Chambon a écrit :
> Q: Do we want to mandate in the specification that switching between
> reading and writing on a read-write object implies a .flush()?
It doesn't and shouldn't be mandated in the specification, IMO. An
implementation should be free to
MRAB mrabarnett.plus.com> writes:
>
> If the characters are always the same number of bytes) then overwriting
> could be possible; that would, however, make the behaviour more
> complicated (sometimes you can, sometimes you can't), so it's probably
> just simpler to forbid read+write text streams
> I personally do not have a problem with that, except that you
> apparently can't grasp his way of thinking, and he apparently can't
> grasp yours.
If I was the only one disagreeing it wouldn't be that annoying (except
for me :-)).
> I'm -1 on PEP 3144 primarily because of this
> communications
Peter Moody hda3.com> writes:
>
> The reason (aside from the name) that I'm not going to include this in
> ipaddr is that it would require the user to deal with two objects when
> one would suffice.
You make it sound like it's a burden, but "dealing" with two objects is not
something extraordina
Peter Moody hda3.com> writes:
>
> > (or would you argue that Address objects should have an optional
distinguishing
> > port number, for "convenience" reasons?)
>
> I'm not sure what you're talking about, I've never argued to add layer
> 4 information to ipaddr.
It was an analogy, just like yo
Peter Moody hda3.com> writes:
>
> On Sun, Sep 27, 2009 at 12:40 PM, James Y Knight fuhm.net> wrote:
> >
> > On Sep 27, 2009, at 3:18 PM, Peter Moody wrote:
> >
> >> administrators) would use it, but it's doable. what you're claiming is
> >> that my use case is invalid.
> >>
> >> that's what I cl
Peter Moody hda3.com> writes:
>
> >> > def parse_net_and_addr(s):
> >> > return (IPNetwork(s), IPAddress(s.split('/')[0]))
> >>
> >> I've only heard talk of new classes and new methods, not new
> >> constructor functions.
> >
> > Well, "method" in that context meant "class method" since the resu
Peter Moody hda3.com> writes:
>
> this is "less useful (strictly removing functionality)" and is an
> example of what I explicitly said I was not going to do with ipaddr.
(please note the conditional wording here) Assuming that a significant number of
people agree that there is a design problem,
Le Mon, 28 Sep 2009 06:41:17 +1000, Nick Coghlan a écrit :
>
> Not as such - a big exception hierarchy rewrite was rejected, but
> nothing specifically limited to the IO exceptions.
>
> Michael's response cut to the heart of the issue though - a richer IO
> exception hierarchy can make life inter
Le Sun, 27 Sep 2009 14:24:52 -0700, Guido van Rossum a écrit :
[truncate()]
>
> What compatibility, though?
Compatibility accross the 3.x line.
> f.truncate() behaves different in 2.x than
> in 3.x, and in 2.x it seems to match the POSIX semantics (i.e. the seek
> position is unchanged even thou
2301 - 2400 of 4909 matches
Mail list logo
