Re: [Python-Dev] [Python-checkins] cpython: fix compiler warnings

2011-10-04 Thread Vlad Riscutia
Why does the function even return a value? As Benjamin said, it is just a bunch of asserts with return 1 at the end. I believe another way you can get rid of statement with no effect is to cast return value to void, like (void)_PyUnicode_CHECK(unicode). Thank you, Vlad On Tue, Oct 4, 2011 at

Re: [Python-Dev] Hg tips (was Re: [Python-checkins] cpython (merge default - default): Merge heads.)

2011-10-02 Thread Vlad Riscutia
Great tips. Can we add them to the developer guide somewhere? Thank you, Vlad On Thu, Sep 29, 2011 at 12:54 AM, Ezio Melotti ezio.melo...@gmail.comwrote: Tip 1 -- merging heads: A while ago Éric suggested a nice tip to make merges easier and since I haven't seen many people using it and now

Re: [Python-Dev] Ctypes and the stdlib (was Re: LZMA compression support in 3.3)

2011-08-30 Thread Vlad Riscutia
I also have some patches sitting on the tracker for some time: http://bugs.python.org/issue12764 http://bugs.python.org/issue11835 http://bugs.python.org/issue12528 which also fixes http://bugs.python.org/issue6069 and http://bugs.python.org/issue11920 http://bugs.python.org/issue6068 which also

Re: [Python-Dev] FileSystemError or FilesystemError?

2011-08-24 Thread Vlad Riscutia
+1 for FileSystemError. I see myself misspelling it as FileSystemError if we go with alternate spelling. I'll probably won't be the only one. Thank you, Vlad On Wed, Aug 24, 2011 at 4:09 AM, Eli Bendersky eli...@gmail.com wrote: When reviewing the PEP 3151 implementation (*), Ezio commented

Re: [Python-Dev] GIL removal question

2011-08-10 Thread Vlad Riscutia
Removing GIL is interesting work and probably multiple people are willing to contribute. Threading and synchronization is a deep topic and it might be that if just one person toys around with removing GIL he might not see performance improvement (not meaning to offend anyone who tried this,

Re: [Python-Dev] Python launcher command line usage (Was: 3.2.1 encoding surprise)

2011-07-22 Thread Vlad Riscutia
, Brian Curtin brian.cur...@gmail.comwrote: On Thu, Jul 21, 2011 at 20:30, Vlad Riscutia riscutiav...@gmail.comwrote: If versioned filenames are added in addition to python.exe, it still might look confusing for most users: Why do I have python and python3.2 executables? What's the difference? I'd

Re: [Python-Dev] ctypes: Configurable bitfield allocation strategy

2011-07-21 Thread Vlad Riscutia
Anyone care to take a look at this? Thank you, Vlad On Mon, Jul 11, 2011 at 8:59 AM, Vlad Riscutia riscutiav...@gmail.comwrote: Actually I already attached patch implementing everything to the issue (not too much time spent :)). I'm hoping someone can review. Thank you, Vlad On Mon, Jul

Re: [Python-Dev] Python launcher command line usage (Was: 3.2.1 encoding surprise)

2011-07-21 Thread Vlad Riscutia
I'm kind of -1 on changing Python executable name. It would make sense for different major versions, where there are known incompatibilities, so python2-python3 would make sense but python31 python32 not that much... If my team is using Python and it gets pre-installed with other dev-tools, do I

Re: [Python-Dev] Python launcher command line usage (Was: 3.2.1 encoding surprise)

2011-07-21 Thread Vlad Riscutia
... Thank you, Vlad On Thu, Jul 21, 2011 at 6:07 PM, Éric Araujo mer...@netwok.org wrote: Hi, Le 22/07/2011 03:03, Vlad Riscutia a écrit : I'm kind of -1 on changing Python executable name. It would make sense for different major versions, where there are known incompatibilities, so python2

Re: [Python-Dev] ctypes: Configurable bitfield allocation strategy

2011-07-11 Thread Vlad Riscutia
Actually I already attached patch implementing everything to the issue (not too much time spent :)). I'm hoping someone can review. Thank you, Vlad On Mon, Jul 11, 2011 at 12:47 AM, Martin v. Löwis mar...@v.loewis.dewrote: Am 25.06.2011 18:33, schrieb Vlad Riscutia: I would like to hear some

Re: [Python-Dev] ctypes: Configurable bitfield allocation strategy

2011-07-10 Thread Vlad Riscutia
Opened http://bugs.python.org/issue12528 to track this. Thank you, Vlad On Sun, Jun 26, 2011 at 5:48 PM, Vlad Riscutia riscutiav...@gmail.comwrote: Well it's not really layout, because alignment is handled by pack option. It is how the field gets allocated. At this point I believe

Re: [Python-Dev] ctypes: Configurable bitfield allocation strategy

2011-06-26 Thread Vlad Riscutia
option (while leaving behavior the same for now), then we can decide how the library interface should look like. Thank you, Vlad On Sat, Jun 25, 2011 at 4:37 PM, Greg Ewing greg.ew...@canterbury.ac.nzwrote: Vlad Riscutia wrote: Longer term though, I think it would be better to add a property

[Python-Dev] ctypes: Configurable bitfield allocation strategy

2011-06-25 Thread Vlad Riscutia
I recently started looking at some ctypes issues. I dug a bit into http://bugs.python.org/issue6069 and then I found http://bugs.python.org/issue11920. They both boil down to the fact that bitfield allocation is up to the compiler, which is different in GCC and MSVC. Currently we have hard-coded

Re: [Python-Dev] ctypes: Configurable bitfield allocation strategy

2011-06-25 Thread Vlad Riscutia
allocation is up to the compiler, it could appear on any other platform due to different compilers being used. On Sat, Jun 25, 2011 at 12:09 PM, Terry Reedy tjre...@udel.edu wrote: On 6/25/2011 12:33 PM, Vlad Riscutia wrote: I recently started looking at some ctypes issues. I dug a bit into http