Re: [Python-Dev] [Python-checkins] cpython (2.7): allow fake filenames in findsource (closes #9284)
On Sun, Jun 12, 2011 at 6:56 AM, benjamin.peterson python-check...@python.org wrote: summary: allow fake filenames in findsource (closes #9284) This allows findsource() to work in doctests. A patch from Dirkjan Ochtman. Either this exception should be mentioned in the inspect.getsource() documentation or else doctest should be monkeypatching inspect as well as linecache. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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-checkins] cpython (2.7): allow fake filenames in findsource (closes #9284)
2011/6/12 Nick Coghlan ncogh...@gmail.com: On Sun, Jun 12, 2011 at 6:56 AM, benjamin.peterson python-check...@python.org wrote: summary: allow fake filenames in findsource (closes #9284) This allows findsource() to work in doctests. A patch from Dirkjan Ochtman. Either this exception should be mentioned in the inspect.getsource() documentation or else doctest should be monkeypatching inspect as well as linecache. I should have made more clear in the message that this is actually a regression from 2.6. -- Regards, Benjamin ___ 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-checkins] cpython (2.7): allow fake filenames in findsource (closes #9284)
On Mon, Jun 13, 2011 at 1:31 AM, Benjamin Peterson benja...@python.org wrote: I should have made more clear in the message that this is actually a regression from 2.6. Actually looking at the inspect docs, I'm not sure where such a note would fit anyway. I'll think about it a bit more - I have a suspicion there may be a flawed assumption in that inspect code and it should be passing more queries through to linecache rather than trying to second-guess it regarding what source code is available. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
[Python-Dev] Implement Aspect-oriented programming
For example, the logging module is not very useful right now, as it requires sprinkling small one-liners all over my code - not exactly ideal. Why not take a page from aspect-oriented programming and allow for injection of code with point cuts? ___ 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
[Python-Dev] Lazy unpacking for struct module
Hi.
We extensively use the struct module to crunch large amounts of binary
data. There are basically two operations for us that only seem to the
naked eye as one: Filtering (see if certain fields have certain
values, throw everything away if not) and inspection (care about all
the fields' values). The filtering-part is very important as most of
the binary data can actually be thrown away and never have to be
inspected any further. When thinking about how to increase
performance, one thought was that a lot of objects are generated by
the struct module that we never need: Unpacking six fields in order to
look at one and then throwing everything away is inefficient
concerning the five other fields. It also makes filtering and
inspecting basically the same operation regarding the (slow) unpacking
of values so we don't really benefit from filtering. This is a huge
problem when crunching gigabytes of data and creating millions of
fields.
One solution to this is using two format-strings instead of only one
(e.g. '4s4s i 4s2s2s'): One that unpacks just the filtered fields
(e.g. '8x i 8x') and one that unpacks all the fields except the one
already created by the filter (e.g. '4s4s 4x 4s2s2s'). This solution
works very well and increases throughput by far. It however also
creates complexity in the code as we have to keep track and combine
field-values that came from the filtering-part with the ones unpacked
during inspection-part (we don't want to simply unpack twice).
I'd like to propose an enhancement to the struct module that should
solve this dilemma and ask for your comments.
The function s_unpack_internal() inside _struct.c currently unpacks
all values from the buffer-object passed to it and returns a tuple
holding these values. Instead, the function could create a tuple-like
object that holds a reference to it's own Struct-object (which holds
the format) and a copy of the memory it is supposed to unpack. This
object allows access to the unpacked values through the sequence
protocol, basically unpacking the fields if - and only if - accessed
through sq_item (e.g. foo = struct.unpack('2s2s', 'abcd'); foo[0] ==
'ab'). The object can also unpack all fields only once (as all
unpacked objects are immutable, we can hold references to them and
return these instead once known). This approach is possible because
there are no further error conditions inside the unpacking-functions
that we would *have* to deal with at the time .unpack() is called; in
other words: Unpacking can't fail if the format-string's syntax had
been correct and can therefor be deferred (while packing can't).
I understand that this may seem like a single-case-optimization. We
can however assume that most people will benefit from the new behavior
unknowingly while everyone else takes now harm: The object mimicking
the otherwise returned tuple is immutable (therefor it's not suddenly
part of GC) and the memory overhead caused by holding references to
the original memory a little longer (reclaimed after the result
becomes unreachable) should be comparable to the memory used by
unneeded fields (reclaimed directly after creation).
I'd like to hear your thoughts and am perfectly willing to provide a
patch if it has a chance of inclusion.
Best regards
Lukas
___
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] Implement Aspect-oriented programming
On Sat, Jun 11, 2011 at 10:29, Jiawei Li jiawei.h...@gmail.com wrote: For example, the logging module is not very useful right now, as it requires sprinkling small one-liners all over my code - not exactly ideal. Why not take a page from aspect-oriented programming and allow for injection of code with point cuts? I'm not sure why you would say this isn't allowed already... -- Lennart Regebro: http://regebro.wordpress.com/ Porting to Python 3: http://python3porting.com/ ___ 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] Implement Aspect-oriented programming
Hi! This mailing list is to work on developing Python (discussing bugs and patches). There is python-ideas mailing list to discuss possible future improvements. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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 3.x and bytes
Guido van Rossum wrote:
On Thu, May 19, 2011 at 1:43 AM, Nick Coghlan wrote:
Proposals to address this include:
- introduce a character literal to allow c'a' as an alternative to ord('a')
-1; the result is not a *character* but an integer. I'm personally
favoring using b'a'[0] and possibly hiding this in a constant
definition.
Using this method, my code now looks like:
# constants
EOH = b'\r'[0]
CHAR = b'C'[0]
DATE = b'D'[0]
FLOAT = b'F'[0]
INT = b'I'[0]
LOGICAL = b'L'[0]
MEMO = b'M'[0]
NUMBER = b'N'[0]
This is not beautiful code.
~Ethan~
___
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] Lazy unpacking for struct module
On Jun 12, 2011, at 8:29 AM, Lukas Lueg wrote:
Hi.
We extensively use the struct module to crunch large amounts of binary
data. There are basically two operations for us that only seem to the
naked eye as one: Filtering (see if certain fields have certain
values, throw everything away if not) and inspection (care about all
the fields' values). The filtering-part is very important as most of
the binary data can actually be thrown away and never have to be
inspected any further. When thinking about how to increase
performance, one thought was that a lot of objects are generated by
the struct module that we never need: Unpacking six fields in order to
look at one and then throwing everything away is inefficient
concerning the five other fields. It also makes filtering and
inspecting basically the same operation regarding the (slow) unpacking
of values so we don't really benefit from filtering. This is a huge
problem when crunching gigabytes of data and creating millions of
fields.
One solution to this is using two format-strings instead of only one
(e.g. '4s4s i 4s2s2s'): One that unpacks just the filtered fields
(e.g. '8x i 8x') and one that unpacks all the fields except the one
already created by the filter (e.g. '4s4s 4x 4s2s2s'). This solution
works very well and increases throughput by far. I
This is what people normally do (unpack just the values they need,
when they need them).
t however also
creates complexity in the code as we have to keep track and combine
field-values that came from the filtering-part with the ones unpacked
during inspection-part (we don't want to simply unpack twice).
I'd like to propose an enhancement to the struct module that should
solve this dilemma and ask for your comments.
The function s_unpack_internal() inside _struct.c currently unpacks
all values from the buffer-object passed to it and returns a tuple
holding these values. Instead, the function could create a tuple-like
object that holds a reference to it's own Struct-object (which holds
the format) and a copy of the memory it is supposed to unpack. This
object allows access to the unpacked values through the sequence
protocol, basically unpacking the fields if - and only if - accessed
through sq_item (e.g. foo = struct.unpack('2s2s', 'abcd'); foo[0] ==
'ab'). The object can also unpack all fields only once (as all
unpacked objects are immutable, we can hold references to them and
return these instead once known). This approach is possible because
there are no further error conditions inside the unpacking-functions
that we would *have* to deal with at the time .unpack() is called; in
other words: Unpacking can't fail if the format-string's syntax had
been correct and can therefor be deferred (while packing can't).
I understand that this may seem like a single-case-optimization.
Yes, it does.
We
can however assume that most people will benefit from the new behavior
unknowingly while everyone else takes now harm: The object mimicking
the otherwise returned tuple is immutable (therefor it's not suddenly
part of GC) and the memory overhead caused by holding references to
the original memory a little longer (reclaimed after the result
becomes unreachable) should be comparable to the memory used by
unneeded fields (reclaimed directly after creation).
I'd like to hear your thoughts and am perfectly willing to provide a
patch if it has a chance of inclusion.
The problem you're trying to solve isn't unique to structs.
That's why we get periodic requests for ropes-like behaviors
for strings for example. Someone could also request lazy
extraction of fields in regular expressions or lazy parses of
json objects.
I don't think there is a net win from adding complexity to the struct
module. Introducing lazy behaviors creates its own overhead
that would compete with code optimized using the traditional
approach (unpack what you need, when you need it). Also,
the new behaviors add to the cognitive load when learning
and remembering how to use this module.
In general, Python has opted for the most straight-forward, least
magical implementations of object (why we use array based
lists instead of blist for example). The are exceptions
such as Python 3's version of super() but this isn't the norm.
I do suggest that you publish your code as a third-party module
to make the optional available and to validate whether there
is any real interest in this.
Raymond
___
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 3.x and bytes
# constants
EOH = b'\r'[0]
CHAR = b'C'[0]
DATE = b'D'[0]
FLOAT = b'F'[0]
INT = b'I'[0]
LOGICAL = b'L'[0]
MEMO = b'M'[0]
NUMBER = b'N'[0]
This is not beautiful code.
In this case, I think the intent would be better captured with
def ASCII(c):
return c.encode('ascii')
EOH = ASCII('\r') # 0D
CHAR= ASCII('C') # 43
DATE= ASCII('D') # 44
FLOAT = ASCII('F') # 46
INT = ASCII('I') # 49
LOGICAL = ASCII('L') # 4C
MEMO= ASCII('M') # 4D
NUMBER = ASCII('N') # 4E
This expresses the intent that a) these are really byte values,
not characters, and b) the specific choice of byte values was motivated
by ASCII.
Regards,
Martin
___
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 3.x and bytes
EOH = b'\r'[0]
CHAR = b'C'[0]
DATE = b'D'[0]
FLOAT = b'F'[0]
INT = b'I'[0]
LOGICAL = b'L'[0]
MEMO = b'M'[0]
NUMBER = b'N'[0]
This is not beautiful code.
You still have the alternative
EOH = ord('\r')
CHAR = ord('C')
...
which looks fine to me.
Cheers,
Hagen
___
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
[Python-Dev] [RELEASE] Python 2.7.2
On behalf of the Python development team, I'm rosy to announce the immediate availability of Python 2.7.2. Since the release candidate 2 weeks ago, there have been 2 changes: 1. pyexpat.__version__ has be changed to be the Python version. 2. A regression from 3.1.3 in the handling of comments in the netrc module has been resolved. (see issue #12009). 2.7.2 is the second in bugfix release for the Python 2.7 series. 2.7 is the last major verison of the 2.x line and will be receiving only bug fixes while new feature development focuses on 3.x. The 2.7 series includes many features that were first released in Python 3.1. The faster io module, the new nested with statement syntax, improved float repr, set literals, dictionary views, and the memoryview object have been backported from 3.1. Other features include an ordered dictionary implementation, unittests improvements, a new sysconfig module, auto-numbering of fields in the str/unicode format method, and support for ttk Tile in Tkinter. For a more extensive list of changes in 2.7, see http://doc.python.org/dev/whatsnew/2.7.html or Misc/NEWS in the Python distribution. To download Python 2.7.2 visit: http://www.python.org/download/releases/2.7.1/ The 2.7.2 changelog is at: http://hg.python.org/cpython/raw-file/eb3c9b74884c/Misc/NEWS 2.7 documentation can be found at: http://docs.python.org/2.7/ This is a production release, please report any bugs to http://bugs.python.org/ Enjoy and for those in the northern hemisphere, have a nice summer! -- Benjamin Peterson Release Manager benjamin at python.org (on behalf of the entire python-dev team and 2.7.2's contributors) ___ 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
[Python-Dev] [RELEASED] Python 3.1.4
On behalf of the Python development team, I'm sanguine to announce a release candidate for the fourth bugfix release for the Python 3.1 series, Python 3.1.4. Since the 3.1.4 release candidate 2 weeks ago, there have been three changes: 1. test_zipfile has been fixed on systems with an ASCII filesystem encoding. 2. pyexpat.__version__ has be changed to be the Python version. 3. A regression from 2.7.1 in the handling of comments in the netrc module has been resolved. (see issue #12009). 3.1.4 will the last bug fix release in the 3.1 series before 3.1. After 3.1.4, 3.1 will be in security-only fix mode. The Python 3.1 version series focuses on the stabilization and optimization of the features and changes that Python 3.0 introduced. For example, the new I/O system has been rewritten in C for speed. File system APIs that use unicode strings now handle paths with undecodable bytes in them. Other features include an ordered dictionary implementation, a condensed syntax for nested with statements, and support for ttk Tile in Tkinter. For a more extensive list of changes in 3.1, see http://doc.python.org/3.1/whatsnew/3.1.html or Misc/NEWS in the Python distribution. This is a production release. To download Python 3.1.4 visit: http://www.python.org/download/releases/3.1.4/ A list of changes in 3.1.4 can be found here: http://hg.python.org/cpython/raw-file/feae9f9e9f30/Misc/NEWS The 3.1 documentation can be found at: http://docs.python.org/3.1 Bugs can always be reported to: http://bugs.python.org Enjoy and be merry! -- Benjamin Peterson Release Manager benjamin at python.org (on behalf of the entire python-dev team and 3.1.4's contributors) ___ 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] Lazy unpacking for struct module
This is what people normally do (unpack just the values they need, when they need them). Due to the fact that there hundreds of format-strings which dynamically compiled from a more verbose language at runtime, we will have significant complexity in the code in order to generate format strings that parse just the fields that are needed for filtering. It's not just put-a-string-here-and-there. I don't think there is a net win from adding complexity to the struct module. Introducing lazy behaviors creates its own overhead that would compete with code optimized using the traditional approach (unpack what you need, when you need it). Also, the new behaviors add to the cognitive load when learning and remembering how to use this module. The complexity is very well handled. Remember that the interface to the module does not change at all and the documentation would be exactly the same. There is no special case introduced here the user has to know about. I also think this case has very little black magic in it since we are dealing only with immutable objects and do not have delayed error conditions (both usually being the primary source of headaches when introducing lazy behavior). ___ 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] [RELEASE] Python 2.7.2
On 6/12/2011 1:57 PM, Benjamin Peterson wrote: To download Python 2.7.2 visit: http://www.python.org/download/releases/2.7.1/ That should be http://www.python.org/download/releases/2.7.2/ -- Terry Jan Reedy ___ 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] [RELEASED] Python 3.1.4
On 12 June 2011 18:58, Benjamin Peterson benja...@python.org wrote: On behalf of the Python development team, I'm sanguine to announce a release candidate for the fourth bugfix release for the Python 3.1 series, Python 3.1.4. Is this actually a RC, or is that a typo? Paul. ___ 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] [RELEASED] Python 3.1.4
2011/6/12 Paul Moore p.f.mo...@gmail.com: On 12 June 2011 18:58, Benjamin Peterson benja...@python.org wrote: On behalf of the Python development team, I'm sanguine to announce a release candidate for the fourth bugfix release for the Python 3.1 series, Python 3.1.4. Is this actually a RC, or is that a typo? That is a typo. This is a final release! Paul. -- Regards, Benjamin ___ 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] Lazy unpacking for struct module
On 6/12/2011 11:29 AM, Lukas Lueg wrote:
This sort of speculative idea might fit the python-ideas list better.
[Summary: we often need to extract a field or two from a binary record
in order to decide whether to toss it or unpack it all and process.]
One solution to this is using two format-strings instead of only one
(e.g. '4s4s i 4s2s2s'): One that unpacks just the filtered fields
(e.g. '8x i 8x') and one that unpacks all the fields except the one
already created by the filter (e.g. '4s4s 4x 4s2s2s'). This solution
works very well and increases throughput by far. It however also
creates complexity in the code as we have to keep track and combine
field-values that came from the filtering-part with the ones unpacked
during inspection-part (we don't want to simply unpack twice).
With just 1 or 2 filter fields, and very many other fields, I would just
unpack everything, including the filter field. I expect the extra time
to do that would be comparalbe to the extra time to combine. It
certainly would make your code easier. I suspect you could write a
function to create the filter field only format by field number from the
everything format.
I'd like to propose an enhancement to the struct module that should
solve this dilemma and ask for your comments.
The function s_unpack_internal() inside _struct.c currently unpacks
all values from the buffer-object passed to it and returns a tuple
holding these values. Instead, the function could create a tuple-like
object that holds a reference to it's own Struct-object (which holds
the format) and a copy of the memory it is supposed to unpack. This
object allows access to the unpacked values through the sequence
protocol, basically unpacking the fields if - and only if - accessed
through sq_item (e.g. foo = struct.unpack('2s2s', 'abcd'); foo[0] ==
'ab'). The object can also unpack all fields only once (as all
unpacked objects are immutable, we can hold references to them and
return these instead once known). This approach is possible because
there are no further error conditions inside the unpacking-functions
that we would *have* to deal with at the time .unpack() is called; in
other words: Unpacking can't fail if the format-string's syntax had
been correct and can therefor be deferred (while packing can't).
I understand that this may seem like a single-case-optimization.
Yep.
We
can however assume that most people will benefit from the new behavior
unknowingly while everyone else takes now harm:
I will not assume that without code and timings. I would expect that
unpacking one field at a time would take longer than all at once. To me,
this is the sort of thing that should be written, listed on PyPI, and
tested by multiple users on multiple systems first.
--
Terry Jan Reedy
___
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
[Python-Dev] is anyone using Misc/RPM?
If no one is using it, I'd like to delete it. I also don't think we should be in business of distributing distribution specific files. -- Regards, Benjamin ___ 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] is anyone using Misc/RPM?
Am 12.06.2011 22:37, schrieb Benjamin Peterson: I also don't think we should be in business of distributing distribution specific files. I disagree. We certainly include PCbuild/*.vcproj, and Tools/msi, which are also distribution-specific. Likewise, we have plenty of OSX-specific files (including special-casing for specific releases thereof). So having an RPM spec file in the source doesn't sound bad to me. Of course, if it's unmaintained (in the sense that it doesn't actually work), I could agree to have it deleted. Make sure Sean Reifschneider doesn't object. People are apparently using it - at least, they report bugs against it: http://bugs.python.org/issue5776 http://bugs.python.org/issue5063 Regards, Martin ___ 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] is anyone using Misc/RPM?
2011/6/12 Martin v. Löwis mar...@v.loewis.de: Am 12.06.2011 22:37, schrieb Benjamin Peterson: I also don't think we should be in business of distributing distribution specific files. I disagree. We certainly include PCbuild/*.vcproj, and Tools/msi, which are also distribution-specific. Likewise, we have plenty of OSX-specific files (including special-casing for specific releases thereof). I should qualify: We shouldn't distribute distribution-specific files for which we don't provide binaries. -- Regards, Benjamin ___ 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 3.x and bytes
Guido van Rossum wrote:
On Thu, May 19, 2011 at 1:43 AM, Nick Coghlan wrote:
Proposals to address this include:
- introduce a character literal to allow c'a' as an alternative to
ord('a')
-1; the result is not a *character* but an integer.
Would you be happier if it were spelled i'a' instead?
--
Greg
___
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] Lazy unpacking for struct module
Raymond Hettinger wrote: The problem you're trying to solve isn't unique to structs. That's why we get periodic requests for ropes-like behaviors I don't think he's asking for rope-like behaviour here. Rather, he's asking for iterator-like or view-like behaviour -- for the same reasons we have both zip() and izip(), for example, or that dict.items() became a view in Py3. It seems like a reasonable request to me. However, I'm wondering whether the ctypes module might already provide what he wants. -- Greg ___ 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] Lazy unpacking for struct module
On Jun 12, 2011, at 3:18 PM, Greg Ewing wrote: Raymond Hettinger wrote: The problem you're trying to solve isn't unique to structs. That's why we get periodic requests for ropes-like behaviors I don't think he's asking for rope-like behaviour here. How would you describe the creation of a lazy result that keeps a reference to the underlying buffer? That is my understanding of how ropes work. Raymond ___ 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] is anyone using Misc/RPM?
Benjamin Peterson writes: I should qualify: We shouldn't distribute distribution-specific files for which we don't provide binaries. Probably it belongs in a contrib area of the tree, but one of the things I find really annoying about distros is the way they refuse to use my perfectly good locally built Python (XEmacs, Mailman, Django, Zope, ...). Having the magic incantation to persuade them that the locally built software satisfies dependencies in the source itself is very convenient. In fact, even if you *do* provide binaries it may be useful to have both the provided installer configuration (which may require things like DBMSes, perhaps several of them) and a bare-bones config for DIYers to use. (Violates TOOWTDI, I know, but PBP sometimes.) ___ 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 3.x and bytes
Ethan Furman writes: Using this method, my code now looks like: # constants [...] This is not beautiful code. Put mascara on a pig, and you have a pig with mascara on, not Bette Davis. I don't necessarily think you're doing anybody a service by making the hack of using ASCII bytes as mnemonics more beautiful. I think Martin's version is as beautiful as this code should get. ___ 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 3.x and bytes
On Mon, Jun 13, 2011 at 3:18 AM, Ethan Furman et...@stoneleaf.us wrote:
This is not beautiful code.
Agreed, but:
EOH, CHAR, DATE, FLOAT, INT, LOGICAL, MEMO, NUMBER = b'\rCDFILMN'
is a shorter way to write the same thing.
Going two per line makes it easier to mentally map the characters:
EOH, CHAR = b'\rC'
DATE, FLOAT = b'DF'
INT, LOGICAL = b'IL'
MEMO, NUMBER = b'MN'
Or, as a variant on Martin's solution:
FORMAT_CHARS = dict(
EOH = '\r',
CHAR= 'C',
DATE = 'D',
FLOAT = 'F',
INT = 'I',
LOGICAL = 'L',
MEMO = 'M',
NUMBER = 'N'
)
FORMAT_CODES = {name : char.encode('ascii') for name, char in FORMAT_CHARS}
globals().update(FORMAT_CODES)
Sure, there's no one obvious way at this stage, but that's because
we don't know yet if there even *should* be an obvious way to do this
(as conflating text and binary data is a bad idea in principle). By
not blessing any one way of handling the situation, we give
alternative solutions time to evolve naturally. If one turns out to be
clearly superior to the decode/process/encode cycle then hopefully
that will become clear at some point in the future.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
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] Lazy unpacking for struct module
On Mon, Jun 13, 2011 at 6:31 AM, Terry Reedy tjre...@udel.edu wrote: With just 1 or 2 filter fields, and very many other fields, I would just unpack everything, including the filter field. I expect the extra time to do that would be comparalbe to the extra time to combine. It certainly would make your code easier. I suspect you could write a function to create the filter field only format by field number from the everything format. Indeed, while the filter format part makes sense to me, the decision to go with field combination rather than just extracting the filter fields a second time isn't such an obvious improvement. OTOH, it also seems like this is something that could be published as a cookbook recipe that generated the appropriate filtered formats on the fly from an existing struct definition. So given format a b c d e, it could either extract each field individually, or else be asked to generate specific formats and their complements (e.g, asking for the 2nd and 3rd field could return a 2-tuple of formats x b c x x and a x x c d e). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
