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 4
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 wrote:
> 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 I got a chance to
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 f
+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 wrote:
>
> When reviewing the PEP 3151 implementation (*), Ezio commented that
>> "FileSys
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,
honestl
at 6:41 AM, Brian Curtin wrote:
> On Thu, Jul 21, 2011 at 20:30, Vlad Riscutia wrote:
>
>> 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
Python
3.1...
Thank you,
Vlad
On Thu, Jul 21, 2011 at 6:07 PM, Éric Araujo 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 in
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 n
Anyone care to take a look at this?
Thank you,
Vlad
On Mon, Jul 11, 2011 at 8:59 AM, Vlad Riscutia wrote:
> Actually I already attached patch implementing everything to the issue (not
> too much time spent :)). I'm hoping someone can review.
>
> Thank you,
> Vlad
>
>
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" wrote:
> Am 25.06.2011 18:33, schrieb Vlad Riscutia:
> > I would like
Opened http://bugs.python.org/issue12528 to track this.
Thank you,
Vlad
On Sun, Jun 26, 2011 at 5:48 PM, Vlad Riscutia wrote:
> 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 it will be more
&
ate a mode 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 wrote:
> Vlad Riscutia wrote:
>
>> Longer term though, I think it would be better to add a proper
field 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 wrote:
> On 6/25/2011 12:33 PM, Vlad Riscutia wrote:
>
>> I recently started looking at some ctypes issues. I dug a
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 al
14 matches
Mail list logo
