Re: [Python-Dev] wait time [was: Ext4 data loss]
Jim Jewett wrote: On 3/12/09, "Martin v. Löwis" wrote: It is starting to look as though flush (and close?) should take an optional wait parameter, to indicate how much re-assurance you're willing to wait for. Unfortunately, such a thing would be unimplementable on most of today's operating systems. What am I missing? _file=file class file(_file): ... def flush(self, wait=0): super().flush(self) if wait < 0.25: return if wait < 0.5 and os.fdatasync: os.fdatasync(self.fileno()) return os.fsync(self.fileno()) if wait < 0.75: return if os.ffullsync: os.ffullsync(self.fileno()) What would be wrong with just making the f*sync calls methods of the file object and that's about it? alternatively when flush() should get an optional argument, I'd call it sync and use a set of predefined and meaningful constants (and no floating point value). Just my 2ct. Regards Tino smime.p7s Description: S/MIME Cryptographic Signature ___ 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
Re: [Python-Dev] [Python-ideas] Proposed addtion to urllib.parse in 3.1 (and urlparse in 2.7)
Hi, Senthil Kumaran wrote: On Mon, Apr 13, 2009 at 5:31 PM, Antoine Pitrou wrote: Say you are filtering or sorting data based on some URL parameters. If the user wants to remove one of those filters, you have to remove the corresponding query parameter. This is a use-case and possibly a hypothetical one which a programmer might do under special situations. There are lots of such use cases for which urllib.parse or urlparse has been used for. But my thoughts with this proposal is do we have a good RFC specfications to implementing this? If not and if we go by just go by the practical needs, then eventually we will end up with bugs or feature requests in this which will take a lot of discussions and time to get fixed. Someone pointed out to read HTML 5.0 spec instead of RFC for this request. I am yet to do that, but my opinion with respect to additions to url* module is - backing of RFCs would be the best way to go and maintain. I'd rather like to see an ordered dict like object returned by urlparse for parameters this would make extra methods superfluous. Also note that you might need to specify the encoding of the data somewhere (most of the times its utf-8 but it depends on the encoding used in the form page). A nice add-on would actually be a template form object which holds all the expected items and their type (and if optional or not) with little wrappers for common types (int, float, string, list, ...) which generate nice execeptions when used somewhere and not filled/no default or actually wrong data for a type. Otoh, this might get a bit too much in direction of a web app framework. Regards Tino ___ 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
Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library
Antoine Pitrou wrote:
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 should and shouldn't be so I wanted to solicit your input on this
pep.
When you say :
« the results of the first computation should be cached and only
re-generated should the object properties change »
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)?
They could impelement __hash__ to behave correctly in this case.
In the examples however I see:
>>> o.broadcast
IPv4Address('1.1.1.255')
this is often used but not the only valid broadcast address,
in fact, any address between network address and max(address with given
netmask) can be defined as broadcast. Maybe biggest or greatest
would be better name for the attribute. User is then free to interpret
it as broadcast if desired.
The attribute network returned as address object also does not seem
right.
The performance hit you mention by translating the object upfront
is neglegtible I'd say - for any sensible use of the object you'd
need the binary form anyway. You can even use system (e.g. socket)
funtions to make the translation very fast. This also safes space
and allow vor verification of the input.
(e.g. '255.255.255.255/32' is 18 bytes where it could
be stored as 8 bytes instead (or even 5 if you use
ip/prefixlength)
I have a very very old implementation which even did the
translation from cidr format to integer in python code
(I don't say plain ;) but maybe worth a look:
http://www.zope.org/Members/tino/IPPatternAuthentication/IPHelper.py/view
Regards
Tino
smime.p7s
Description: S/MIME Cryptographic Signature
___
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
Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library
Peter Moody wrote:
On Wed, Aug 19, 2009 at 6:47 AM, Tino Wildenhain wrote:
Antoine Pitrou wrote:
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 should and shouldn't be so I wanted to solicit your input on this
pep.
When you say :
« the results of the first computation should be cached and only
re-generated should the object properties change »
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)?
They could impelement __hash__ to behave correctly in this case.
In the examples however I see:
o.broadcast
IPv4Address('1.1.1.255')
this is often used but not the only valid broadcast address,
in fact, any address between network address and max(address with given
netmask) can be defined as broadcast. Maybe biggest or greatest
would be better name for the attribute. User is then free to interpret
it as broadcast if desired.
The attribute network returned as address object also does not seem
right.
by convention, the highest address in a given network is called the
broadcast address while the lowest address is called the network
address. They're also distinct addresses, as opposed to networks,
hence .broadcast/.network/etc returning IPvXAddress objects. calling
them .biggest and .smallest would be confusing.
am I misinterpreting what you mean?
No, I just said its conventionally used as that but its not definition
of a broadcast (in fact you can have any valid host address defined
as broadcast as long as all members of the network agree on that)
Since you dont want to call the attribute ususally_the_broadcast_address
or something, other names which tell you about the data would seem more
appropriate (like greatest)
The performance hit you mention by translating the object upfront
is neglegtible I'd say - for any sensible use of the object you'd
need the binary form anyway. You can even use system (e.g. socket)
funtions to make the translation very fast. This also safes space
and allow vor verification of the input.
I'll look into using socket where I can, but the computational hit
actually wasn't negligible. A common use for something like this
library might be to verify that an addresses typed by a user is valid,
'192.168.1.1' instead os '1921.68.1.1'; computing the extra attributes
delays the return time and doesn't actually benefit the user or
programmer.
Maybe I don't quite understand your extra attributes stuff - the
32 bit integer for ipv4 IP and the netmask in either 32 bit
or prefix length in 5 bits would be enough of a storage attribute.
All others are just representation of the values.
Storing the data as string seems a bit suboptimal since for
any sensible operation with the data you'd need to do the
conversion anyway.
Regards
Tino
smime.p7s
Description: S/MIME Cryptographic Signature
___
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
Re: [Python-Dev] [Zope-dev] Syntax error in python2.6
Bristow Thankachan wrote: Hi everybody, During the porting of Zope2 to Python2.6, I am stuck with a syntax error in the module AccessControl, which is given below. def reorder(s, with=None, without=()): ^ SyntaxError: invalid syntax in line 56 of /home/zope/ztrunk26/lib/python/RestrictedPython/Utilities.py. The same code when run in python2.4 and python2.5 didn't give any syntax errors. Can anybody suggest the reason for this syntax error in python2.6. I'd say, "with" is now a keyword. http://docs.python.org/ref/keywords.html btw, shouldn't this already give a warning in 2.5? Cheers Tino smime.p7s Description: S/MIME Cryptographic Signature ___ 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
Re: [Python-Dev] PEP 3142: Add a "while" clause to generator expressions
Hi, Gerald Britton wrote: The sieve is just one example. The basic idea is that for some infinite generator (even a very simple one) you want to cut it off after some point. As for the number of characters, I spelled lambda incorrectly (left out a b) and there should be a space after the colon to conform to design guides. So, actually the takewhile version is two characters longer, not counting "import itertools" of course! the only usefull approach I could see is to enable slice syntax on generators which would make it possible to describe the exact or maximum lenght of results you want out of it. something like: >> g=(i for i in xrange(1000))[2:5] >> g.next() # wrapper would now step 2 times w/o yield and 1 with yield 2 >> g.next() 3 >> g.next() 4 >> g.next() Traceback (most recent call last): File "", line 1, in StopIteration as expected - this could be included into itertools for now. Regards Tino On Mon, Jan 19, 2009 at 11:44 AM, Daniel Stutzbach wrote: On Mon, Jan 19, 2009 at 10:37 AM, Gerald Britton wrote: prime = (p for p in sieve() while p < 1000) prime = takewhile(lamda p:p<1000, sieve()) I'm pretty sure the extra cost of evaluating the lambda at each step is tiny compared to the cost of the sieve, so I don't you can make a convincing argument on performance. Also, you know the latter is actually fewer characters, right? :-) -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC ___ 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/tino%40wildenhain.de smime.p7s Description: S/MIME Cryptographic Signature ___ 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
Re: [Python-Dev] PEP 3142: Add a "while" clause to generator expressions
Nick Coghlan wrote: Tino Wildenhain wrote: g=(i for i in xrange(1000))[2:5] g.next() # wrapper would now step 2 times w/o yield and 1 with yield 2 g.next() 3 g.next() 4 g.next() Traceback (most recent call last): File "", line 1, in StopIteration as expected - this could be included into itertools for now. Slicing of arbitrary iterators has been supported by itertools ever since the module was first added to the standard library. from itertools import islice g = islice((i for i in xrange(1000)), 2, 5) list(g) [2, 3, 4] Yeah right, I actually believed it is already there but didn't bother to check ;-) Thx Tino smime.p7s Description: S/MIME Cryptographic Signature ___ 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
