[issue3177] implement os.startfile on posix and MacOSX

[Chris Rebert]

Changes by Chris Rebert :


--
nosy: +cvrebert

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12524] change httplib docs POST example

[Georg Brandl]

New submission from Georg Brandl :

The POST example in the httplib docs references musi-cal.mojam.com, which is 
now defunct.

--
assignee: docs@python
components: Documentation
keywords: easy
messages: 140074
nosy: docs@python, georg.brandl
priority: low
severity: normal
status: open
title: change httplib docs POST example

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12491] Update glossary documentation for the term 'attribute'

[Raymond Hettinger]

Raymond Hettinger  added the comment:

The current glossary entry is fine and encompasses was is ordinarily meant by 
attribute as distinct from a method.

We sometimes use the term loosely to mean any value whether callable or not.  
And sometimes it is used loosely to mean anything that can be looked up with 
getattr().

Attempts to over-define it will be incorrect for some uses.  Also, it is likely 
to make the glossary entry less understandable.

--
assignee: docs@python -> rhettinger
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12491] Update glossary documentation for the term 'attribute'

[R. David Murray]

R. David Murray  added the comment:

As an experienced Python programmer, I think of 'attribute' as meaning any 
attribute (method or non-method) of an object or class.  I sometimes do use it 
imprecisely (to my mind) to mean "non-method attribute", and it is usually 
clear from context what I mean.

Raymond, if attribute means only non-method attributes, what is the word for 
the set of things that contains both method and non-method...ah, 
attributes...of an object?

(I thought we already had this discussion both on python-dev and another 
issue)

Hmm.  Actually looking at the linked entry, it looks correct to me (it covers 
both method and non-method attributes as far as I can see).  It might be 
clearer if it mentioned that a value can be anything, including a method.

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12523] 'str' object has no attribute 'more' [/usr/lib/python3.2/asynchat.py|initiate_send|245]

[R. David Murray]

Changes by R. David Murray :


--
components: +Library (Lib) -None
nosy: +giampaolo.rodola

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12525] Unable to run a thread

[Amandeep Singh]

New submission from Amandeep Singh :

I created a thread, and started it and then called its run method. It raised an 
AttributeError exception


from threading import Thread

def func():
  print 'abc'

t = Thread(None, func)
t.start()
t.run()

here t.run() raises an exception.

--
components: Build
messages: 140077
nosy: newtodisworld
priority: normal
severity: normal
status: open
title: Unable to run a thread
type: behavior
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12523] 'str' object has no attribute 'more' [/usr/lib/python3.2/asynchat.py|initiate_send|245]

[R. David Murray]

Changes by R. David Murray :


--
type: crash -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12491] Update glossary documentation for the term 'attribute'

[R. David Murray]

R. David Murray  added the comment:

OK, I found the other issue and it looks like we agreed to use 'attributes and 
methods' where the reference was inclusive.  I still think that it is less 
precise to think this way, but it is clearer exposition given the lack of a 
good term for non-method attributes.  So now I agree that we should not change 
the existing glossary definition of attribute.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12525] Unable to run a thread

[Eric V. Smith]

Eric V. Smith  added the comment:

Don't call both start() and run(). From the documentation, start() arranges for 
run() to be called. After the call to start(), 'abc' is printed.

--
components: +Extension Modules -Build
nosy: +eric.smith
resolution:  -> invalid
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12525] Unable to run a thread

[Amandeep Singh]

Amandeep Singh  added the comment:

I am also not able to call run() twice. I have python 2.5.2 with me, in which I 
am able to call run method twice and calling run after start is working.

--
status: pending -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12525] Unable to run a thread

[Amandeep Singh]

Amandeep Singh  added the comment:

May be this is a behavior change, that a thread can not be run again. I think 
documentation needs to be changed in this case.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12525] Unable to run a thread

[Georg Brandl]

Georg Brandl  added the comment:

While it's not explicitly documented that run() also shouldn't be called 
multiple times, it does not need to be supported.  Threads can be started 
exactly once -- this is already mentioned in the docs.

Note that run() simply calls the thread target with the given args.  Calling 
thread.run() instead is just a more confusing way of doing this.

--
nosy: +georg.brandl
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12526] packaging.pypi.Crawler and resulting objects have a circular API

[Michael Mulich]

New submission from Michael Mulich :

The issue, as best I can describe it, is in how the a release list 
(packaging.pypi.dist.ReleaseList) looks up releases.

Here is a simple example using a random package on PyPI.

>>> crawler = Crawler()
>>> projects = crawler.search_projects('snimpy')
>>> projects
[]
>>> project = projects[0]
>>> [x for x in project]
[]

The results show that project 'snimpy' has no releases, but this is incorrect 
because distribution 'snimpy' has five releases.

Even after calling sort_releases and fetch_releases on the project which both 
refer back to the crawler instance (see the project's _index attribute) the 
project fails to get the releases.

>>> project.fetch_releases()
[]
>>> project.sort_releases()
>>> [x for x in project]
[]

In order to get the releases, one is forced to use the crawler's
API rather than the resulting project's API.

>>> crawler.get_releases(project.name, force_update=True)

>>> [x for x in project]
[, , , , ]

So as far as I can gather, We lack the ability to forcibly update the project 
(or ReleaseList). I don't have a solution at this time, but we may want to look 
into adding a force_update argument to the get_release method on the Crawler.

--
assignee: tarek
components: Distutils2
messages: 140083
nosy: alexis, eric.araujo, michael.mulich, tarek
priority: normal
severity: normal
status: open
title: packaging.pypi.Crawler and resulting objects have a circular API
type: behavior
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12527] assertRaisesRegex doc'd with 'msg' arg, but it's not implemented?

[Brian Jones]

New submission from Brian Jones :

The documentation here:
http://docs.python.org/dev/library/unittest.html#unittest.TestCase.assertRaisesRegex

Indicates that, when used as a context manager, assertRaisesRegex should accept 
a keyword argument 'msg'. However, that doesn't appear to actually be 
implemented. I've just now done an hg pull, and in Lib/unittest/case.py, the 
source is here: 

def assertRaisesRegex(self, expected_exception, expected_regex,
  callable_obj=None, *args, **kwargs):
"""Asserts that the message in a raised exception matches a regex.

Args:
expected_exception: Exception class expected to be raised.
expected_regex: Regex (re pattern object or string) expected
to be found in error message.
callable_obj: Function to be called.
msg: Optional message used in case of failure. Can only be used
when assertRaisesRegex is used as a context manager.
args: Extra args.
kwargs: Extra kwargs.
"""
context = _AssertRaisesContext(expected_exception, self, callable_obj,
   expected_regex)

return context.handle('assertRaisesRegex', callable_obj, args, kwargs)

I noticed this after attempting some simple example uses of assertRaisesRegex. 
Perhaps I'm just missing something that will be made obvious to others by 
seeing them. These are just various attempts to get my msg shown somewhere in 
the output: 

#!/usr/bin/env python3.3
import unittest

class TestInt(unittest.TestCase):
def test_intfail(self):
# this test should *not* fail, and doesn't
with self.assertRaisesRegex(ValueError, 'literal'):
int('XYZ')

def test_intfail2(self):
# should not fail, and doesn't
with self.assertRaisesRegex(ValueError, 'lambda', msg='Foo!'):
int('ABC')

def test_intfail3(self):
# should fail, and does, but no msg to be found.
with self.assertRaisesRegex(ValueError, 'literal', msg='Foo!'):
int(1)

def test_intfail4(self):
# should fail, and does, but no msg to be found.
with self.assertRaisesRegex(TypeError, 'literal', msg='Foo!'):
int('ABC')

if __name__ == '__main__':
unittest.main()

--
components: Library (Lib)
messages: 140084
nosy: Brian.Jones
priority: normal
severity: normal
status: open
title: assertRaisesRegex doc'd with 'msg' arg, but it's not implemented?
type: behavior
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12527] assertRaisesRegex doc'd with 'msg' arg, but it's not implemented?

[Benjamin Peterson]

Benjamin Peterson  added the comment:

You're not getting this?

.FFE
==
ERROR: test_intfail4 (__main__.TestInt)
--
Traceback (most recent call last):
  File "x.py", line 22, in test_intfail4
int('ABC')
ValueError: invalid literal for int() with base 10: 'ABC'

==
FAIL: test_intfail2 (__main__.TestInt)
--
ValueError: invalid literal for int() with base 10: 'ABC'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "x.py", line 12, in test_intfail2
int('ABC')
AssertionError: "lambda" does not match "invalid literal for int() with base 
10: 'ABC'" : Foo!

==
FAIL: test_intfail3 (__main__.TestInt)
--
Traceback (most recent call last):
  File "x.py", line 17, in test_intfail3
int(1)
AssertionError: ValueError not raised : Foo!

--
Ran 4 tests in 0.001s

FAILED (failures=2, errors=1)

--
nosy: +benjamin.peterson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12527] assertRaisesRegex doc'd with 'msg' arg, but it's not implemented?

[Brian Jones]

Brian Jones  added the comment:

No, I'm not. I'm sorry for not including this output initially. Here's what I 
get (and I've added a sys.version_info line just to be double sure the right 
executable is being invoked at runtime): 

sys.version_info(major=3, minor=3, micro=0, releaselevel='alpha', serial=0)
.FFE
==
ERROR: test_intfail4 (__main__.TestInt)
--
Traceback (most recent call last):
  File "./test_int.py", line 21, in test_intfail4
int('ABC')
ValueError: invalid literal for int() with base 10: 'ABC'

==
FAIL: test_intfail2 (__main__.TestInt)
--
ValueError: invalid literal for int() with base 10: 'ABC'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./test_int.py", line 13, in test_intfail2
int('ABC')
AssertionError: "lambda" does not match "invalid literal for int() with base 
10: 'ABC'"

==
FAIL: test_intfail3 (__main__.TestInt)
--
Traceback (most recent call last):
  File "./test_int.py", line 17, in test_intfail3
int(1)
AssertionError: ValueError not raised

--
Ran 4 tests in 0.001s

FAILED (failures=2, errors=1)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12527] assertRaisesRegex doc'd with 'msg' arg, but it's not implemented?

[Brian Jones]

Brian Jones  added the comment:

If there's some reason, based on the source snippet I posted from case.py, that 
my msg should be making it to the output, can someone explain why/how it should 
get there? I don't see any reason, from looking at the source, that 'msg' 
should even be expected to make it to the output.  Thanks!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12528] Implement configurable bitfield allocation strategy

[Vlad Riscutia]

New submission from Vlad Riscutia :

Opened this issue to track configurable bitfield allocation strategy. This will 
address issues like http://bugs.python.org/issue6069, 
http://bugs.python.org/issue11920.

Summary: the way bitfields are allocated is up to the compiler not defined by 
standard. MSVC and GCC have different strategies to perform the allocation so 
the size of bitfield structures can be different depending on compiler. 
Currently we hardcode allocation strategy to be GCC-way on non-Windows and 
MSVC-way on Windows which raises issues when trying to interop on Windows with 
GCC binaries.

Short term this solution will enable interop between MSVC compiled Python with 
GCC compiled binaries under Windows. It will also enable addressing other 
possible compiler interop issues in the future, for compilers that don't use 
GCC strategy.

Following is copied from thread discussing this:


On 6/25/2011 12:33 PM, Vlad Riscutia wrote:
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 allocation strategy based on paltform
in cfields.c:

 if (bitsize /* this is a bitfield request */

   &&  *pfield_size /* we have a bitfield open */
 #ifdef MS_WIN32
   /* MSVC, GCC with -mms-bitfields */
   &&  dict->size * 8 == *pfield_size
 #else
   /* GCC */
   &&  dict->size * 8<= *pfield_size
 #endif
   &&  (*pbitofs + bitsize)<= *pfield_size) {
   /* continue bit field */
   fieldtype = CONT_BITFIELD;
 #ifndef MS_WIN32
   } else if (bitsize /* this is a bitfield request */
   &&  *pfield_size /* we have a bitfield open */
   &&  dict->size * 8>= *pfield_size
   &&  (*pbitofs + bitsize)<= dict->size * 8) {
   /* expand bit field */
   fieldtype = EXPAND_BITFIELD;
 #endif

So when creating a bitfield structure, it's size can be different on
Linux vs Windows.

class MyStructure(ctypes.BigEndianStructure):
_pack_  = 1# aligned to 8 bits, not ctypes default of 32
_fields_= [
   ("Data0",   ctypes.c_uint32, 32),
   ("Data1",   ctypes.c_uint8, 3),
   ("Data2",   ctypes.c_uint16, 12),
  ]

sizeof for above structure is 6 on GCC build and 7 on MSVC build. This
leads to some confusion and issues, because we can't always interop
correctly with code compiled with different compiler than the one Python
is compiled with on the platform.

Just curious, are you saying that this is the 'cause' of the two bug reports, 
or 'just' something you discovered while investigating them?


> Short term solution is to add a warning in the documentation about this.

For 2.7/3.2, yes.


> Longer term though, I think it
would be better to add a property on the Structure class for
configurable allocation strategy, for example Native (default), GCC,
MSVC and when allocating the bitfield, use given strategy. Native would
behave similar to what happens now, but we would also allow GCC-style
allocation on Windows for example and the ability to extend this if we
ever run into similar issues with other compilers. This shouldn't be too
difficult to implement, will be backwards compatible and it would
improve interop. I would like to hear some opinions on this.

If this would allow the MSVC-compilied Python to better access dlls compiled 
with gcc (cygwin) on Windows, definitely -- in 3.3.
If the new feature is (currently) only useful on Windows, doc should say so.

-- 
Terry Jan Reedy

/copy

Attached is patch with initial refactoring of cfield.c to enable configurable 
allocation. Next step is to provide a way to configure this through Python 
library. I will also look at updating documentation to point out the known 
issue.

--
components: ctypes
files: cfield_bitfield_refactoring.diff
keywords: patch
messages: 140088
nosy: terry.reedy, vladris
priority: normal
severity: normal
status: open
title: Implement configurable bitfield allocation strategy
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22617/cfield_bitfield_refactoring.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11920] ctypes: Strange bitfield structure sizing issue

[Vlad Riscutia]

Vlad Riscutia  added the comment:

Opened http://bugs.python.org/issue12528 to address this.

--
nosy: +vladris

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6069] casting error from ctypes array to structure

[Vlad Riscutia]

Vlad Riscutia  added the comment:

Opened http://bugs.python.org/issue12528 to address this.

--
versions: +Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12528] Implement configurable bitfield allocation strategy

[Santoso Wijaya]

Changes by Santoso Wijaya :


--
nosy: +santa4nt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12529] cgi.parse_header fails on double quotes and semicolons

[Ben Darnell]

New submission from Ben Darnell :

cgi.parse_header doesn't work on headers that contain combinations of double 
quotes and semicolons (although it works with either type of character 
individually).  

>>> cgi.parse_header('form-data; name="files"; filename="fo\\"o;bar"')
('form-data', {'name': 'files', 'filename': '"fo\\"o'})

This issue is present in python 2.7 and 3.2.  One solution is to change 
_parseparam as follows (same as email.message._parseparam):

def _parseparam(s):
while s[:1] == ';':
s = s[1:]
end = s.find(';')
while end > 0 and (s.count('"', 0, end) - s.count('\\"', 0, end)) % 2:
end = s.find(';', end + 1)
if end < 0:
end = len(s)
f = s[:end]
yield f.strip()
s = s[end:]

--
messages: 140091
nosy: Ben.Darnell
priority: normal
severity: normal
status: open
title: cgi.parse_header fails on double quotes and semicolons

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12528] Implement configurable bitfield allocation strategy

[Vlad Riscutia]

Vlad Riscutia  added the comment:

Removed previously attached partial patch, this is complete patch.

Summary:
Added following 3 constants in ctypes:
ctypes.BITFIELD_ALLOCATION_NATIVE
ctypes.BITFIELD_ALLOCATION_GCC
ctypes.BITFIELD_ALLOCATION_MSVC

Setting _bitfield_allocation_ attribute to one of these on a class declaration 
inheriting from Structure will force specified allocation of the bitfield.

NATIVE is equivalent to not specifying anything. 
GCC will do GCC-style allocation (what Python does now on non-Windows)
MSVC will do MSVC-style allocation (what Python does now on Windows)

I added unittests to cover these and ran full suit on both Windows and Linux.

Still have to update documentation to mention this. Will submit diff for that 
after this gets reviewed.

--
Added file: 
http://bugs.python.org/file22618/configurable_bitfield_allocation.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12528] Implement configurable bitfield allocation strategy

[Vlad Riscutia]

Changes by Vlad Riscutia :


Removed file: http://bugs.python.org/file22617/cfield_bitfield_refactoring.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12491] Update glossary documentation for the term 'attribute'

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
resolution:  -> rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12343] ssl documentation needs comments about non-blocking behaviour

[Roundup Robot]

Roundup Robot  added the comment:

New changeset b763c1ba5589 by Antoine Pitrou in branch '3.2':
Issue #12343: Add some notes on behaviour of non-blocking SSL sockets.
http://hg.python.org/cpython/rev/b763c1ba5589

New changeset 77334eb5038d by Antoine Pitrou in branch 'default':
Issue #12343: Add some notes on behaviour of non-blocking SSL sockets.
http://hg.python.org/cpython/rev/77334eb5038d

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12343] ssl documentation needs comments about non-blocking behaviour

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I'd say this is fixed now. Tell me if there are any precisions you would like 
to see added.

--
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions:  -Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8161] inconsistency behavior in ctypes.c_char_p dereferencing

[Vlad Riscutia]

Vlad Riscutia  added the comment:

Looks like this was implemented by design at some point. In cfield.c, we have 
specific code to treat character array fields as strings:

/*  Field descriptors for 'c_char * n' are be scpecial cased to
return a Python string instead of an Array object instance...
*/
if (PyCArrayTypeObject_Check(proto)) {
StgDictObject *adict = PyType_stgdict(proto);
StgDictObject *idict;
if (adict && adict->proto) {
idict = PyType_stgdict(adict->proto);
if (!idict) {
PyErr_SetString(PyExc_TypeError,
"has no _stginfo_");
Py_DECREF(self);
return NULL;
}
if (idict->getfunc == _ctypes_get_fielddesc("c")->getfunc) {
struct fielddesc *fd = _ctypes_get_fielddesc("s");
getfunc = fd->getfunc;
setfunc = fd->setfunc;
}
#ifdef CTYPES_UNICODE
if (idict->getfunc == _ctypes_get_fielddesc("u")->getfunc) {
struct fielddesc *fd = _ctypes_get_fielddesc("U");
getfunc = fd->getfunc;
setfunc = fd->setfunc;
}
#endif
}
}

Simple fix would be to just remove this whole section though this might break 
code which relied on string assignment to such fields. For example:

class T(ctypes.Structure):
_fields_ = (
('member', ctypes.c_char * 16),
)

x = T()
x.member = bytes('Spam', 'ascii')

Above works now but will fail if change is made. There is a high chance this 
would break existing code as I imagine people using this due to convenience. An 
alternative would be to keep string setfunc but don't change getfunc, though 
that is also pretty inconsistent as you will be able to set a string but not 
get one back.

If we are willing to take the risk, fix is easy.

--
nosy: +vladris

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6493] Can not set value for structure members larger than 32 bits

[Vlad Riscutia]

Vlad Riscutia  added the comment:

I have a similar patch for issue 6068. I wasn't aware of this issue when I 
looked into it.

I believe both patches fix the same thing (please take a look and correct me if 
I'm wrong). My fix: we don't need to treat Windows differently, just remove 
#ifdef and 

#define BIT_MASK(size) ((1LL << NUM_BITS(size))-1)

regardless of platform. Unittests for this patch pass for my patch too. I 
believe this is some old #ifdef that was put in place due to a compiler bug 
which got fixed since then.

--
nosy: +vladris

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12529] cgi.parse_header fails on double quotes and semicolons

[R. David Murray]

R. David Murray  added the comment:

The email module header parser handles this correctly (if you make it a real 
header).  For whatever that's worth :)

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12142] Reference cycle when importing ctypes

[Vlad Riscutia]

Vlad Riscutia  added the comment:

I ran full test suit after making the _array_type = type(Array) change and 
everything passes.

I also took a look at this and found additional leak. gc shows this as garbage:

[(,), , , , (, , , ), {'__dict__': , '_type_': 'g', '__module__': 'ctypes', '__weakref__': , '__doc__': None}]

This is all caused by these lines in ctypes __init__.py:

class c_longdouble(_SimpleCData):
_type_ = "g"
if sizeof(c_longdouble) == sizeof(c_double):
c_longdouble = c_double

For me sizeof(c_longdouble) == sizeof(c_double) (I believe MS compiler always 
does this) but when we assign c_longdouble = c_double, there is a leak. I 
removed the alias lines:

if sizeof(c_longdouble) == sizeof(c_double):
c_longdouble = c_double

And the leak was gone. Looks like changing c_longdouble after declaring it 
causes a leak. Below for similar aliasing of longlong types, we have this:

if _calcsize("l") == _calcsize("q"):
# if long and long long have the same size, make c_longlong an alias for 
c_long
c_longlong = c_long
c_ulonglong = c_ulong
else:
class c_longlong(_SimpleCData):
_type_ = "q"
_check_size(c_longlong)

class c_ulonglong(_SimpleCData):
_type_ = "Q"

This avoids declaring c_longlong and c_ulonglong as class if not needed to. The 
problem is _calcsize("g") causes an error because "g" is used as long double 
througout ctypes but _calcsize is function from _struct.c, where "g" (long 
double) is not defined. Not sure why it isn't...

So in short:
As far as I can tell _array_type = type(Array) doesn't break anything
Looks like we have another leak in ctypes (which isn't a big deal)
We have elegant fix for the leak once _struct.c will support long double

--
nosy: +vladris

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12530] cpython 3.3, __class__ missing.

[Campbell Barton]

New submission from Campbell Barton :

In python 3.2 this works and prints ,
in cpython hg: 71296:ab162f925761 it fails with:
 NameError: global name '__class__' is not defined

Since this change is not documented I assume its a bug.

--- snip ---
class Test:
  def __init__(self): print(__class__)

--
components: Interpreter Core
messages: 140099
nosy: ideasman42
priority: normal
severity: normal
status: open
title: cpython 3.3, __class__ missing.
type: behavior
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12530] cpython 3.3, __class__ missing.

[Campbell Barton]

Campbell Barton  added the comment:

checked for docs here:
http://docs.python.org/dev/whatsnew/3.3.html

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12530] cpython 3.3, __class__ missing.

[Benjamin Peterson]

Benjamin Peterson  added the comment:

No, this is consistent (again) with Python 2.

--
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

[Alec Koumjian]

Alec Koumjian  added the comment:

I apologize if this is the wrong place for this message. I did not see the link 
to a separate list.

First let me explain what I am trying to accomplish. I would like to be able to 
take an unknown regular expression that contains both named and unnamed groups 
and tag their location in the original string where a match was found. Take the 
following redundantly simple example:

>>> a_string = r"This is a demo sentence."
>>> pattern = r"(?\w+) (\w+) (?\w+)"
>>> m = regex.search(pattern, a_string)

What I want is a way to insert named/numbered tags into the original string, so 
that it looks something like this:

r"This <2>is a demo 
sentence."

The syntax doesn't have to be exactly like that, but you get the place. I have 
inserted the names and/or indices of the groups into the original string, 
around the span that the groups occupy. 

This task is exceedingly difficult with the current implementation, unless I am 
missing something obvious. We could call the groups by index, the groups as a 
tuple, or the groupdict:

>>> m.group(1)
'This'
>>> m.groups()
('This', 'is', 'a')
>>> m.groupdict()
{'another_thing': 'a', 'a_thing': 'This'}

If all I wanted was to tag the groups by index, it would be a simple function. 
I would be able to call m.spans() for each index in the length of m.groups() 
and insert the <> and  tags around the right indices.

The hard part is finding out how to find the spans of the named groups. Do any 
of you have a suggestion?

It would make more sense from my perspective, if each group was an object that 
had its own .span property. It would work like this with the above example:

>>> first = m.group(1)
>>> first.name()
'a_thing'
>>> second = m.group(2)
>>> second.name()
None
>>>

You could still call .spans() on the Match object itself, but it would query 
its children group objects for the data. Overall I think this would be a much 
more Pythonic approach, especially given that you have added subscripting and 
key lookup.

So instead of this:
>>> m['a_thing']
'This'
>>> type(m['a_thing'])


You could have:
>>> m['a_thing']
'This'
>>> type(m['a_thing'])
<'regex.Match.Group object'>

With the noted benefit of this:
>>> m['a_thing'].span()
(0, 4)
>>> m['a_thing'].index()
1
>>>

Maybe I'm missing a major point or functionality here, but I've been pouring 
over the docs and don't currently think what I'm trying to achieve is possible.

Thank you for taking the time to read all this.

-Alec

--
nosy: +akoumjian
versions:  -Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue874900] malloc

[Nir Aides]

Changes by Nir Aides :


--
title: threading module can deadlock after fork -> malloc

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue874900] threading module can deadlock after fork

[Nir Aides]

Changes by Nir Aides :


--
title: malloc -> threading module can deadlock after fork

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12530] cpython 3.3, __class__ missing.

[Campbell Barton]

Campbell Barton  added the comment:

Shouldn't it be documented that it changes still? - since people are using 
pytjon3.2 and its a stable release, _any_ breaking change should be documented 
IMHO

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com