Custom Query (121 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (58 - 60 of 121)

Ticket Resolution Summary Owner Reporter
#135 invalid PyYaml 3.08 w/ python 3.1 os x xi jjdenis@…

Reported by jjdenis@…, 5 years ago.

Description

I can not setup PyYaml? 3.08 to work with python 3.1 under os x

imac:PyYAML-3.08 jjdenis$ python setup.py install
running install
running build
running build_py
creating build
creating build/lib.macosx-10.5-i386-2.5
creating build/lib.macosx-10.5-i386-2.5/yaml
copying lib/yaml/__init__.py -> build/lib.macosx-10.5-i386-2.5/yaml
copying lib/yaml/composer.py -> build/lib.macosx-10.5-i386-2.5/yaml
copying lib/yaml/constructor.py -> build/lib.macosx-10.5-i386-2.5/yaml
copying lib/yaml/cyaml.py -> build/lib.macosx-10.5-i386-2.5/yaml
copying lib/yaml/dumper.py -> build/lib.macosx-10.5-i386-2.5/yaml
copying lib/yaml/emitter.py -> build/lib.macosx-10.5-i386-2.5/yaml
copying lib/yaml/error.py -> build/lib.macosx-10.5-i386-2.5/yaml
copying lib/yaml/events.py -> build/lib.macosx-10.5-i386-2.5/yaml
copying lib/yaml/loader.py -> build/lib.macosx-10.5-i386-2.5/yaml
copying lib/yaml/nodes.py -> build/lib.macosx-10.5-i386-2.5/yaml
copying lib/yaml/parser.py -> build/lib.macosx-10.5-i386-2.5/yaml
copying lib/yaml/reader.py -> build/lib.macosx-10.5-i386-2.5/yaml
copying lib/yaml/representer.py -> build/lib.macosx-10.5-i386-2.5/yaml
copying lib/yaml/resolver.py -> build/lib.macosx-10.5-i386-2.5/yaml
copying lib/yaml/scanner.py -> build/lib.macosx-10.5-i386-2.5/yaml
copying lib/yaml/serializer.py -> build/lib.macosx-10.5-i386-2.5/yaml
copying lib/yaml/tokens.py -> build/lib.macosx-10.5-i386-2.5/yaml
running build_ext
creating build/temp.macosx-10.5-i386-2.5
checking if libyaml is compilable
gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -Os -Wall -Wstrict-prototypes -DMACOSX -I/usr/include/ffi -DENABLE_DTRACE -arch i386 -arch ppc -pipe -I/System/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -c build/temp.macosx-10.5-i386-2.5/check_libyaml.c -o build/temp.macosx-10.5-i386-2.5/check_libyaml.o
unable to execute gcc: No such file or directory

libyaml is not found or a compiler error: forcing --without-libyaml
(if libyaml is installed correctly, you may need to
 specify the option --include-dirs or uncomment and
 modify the parameter include_dirs in setup.cfg)
running install_lib
running install_egg_info
Removing /Library/Python/2.5/site-packages/PyYAML-3.08-py2.5.egg-info
Writing /Library/Python/2.5/site-packages/PyYAML-3.08-py2.5.egg-info
imac:PyYAML-3.08 jjdenis$ python3
Python 3.1 (r31:73578, Jun 27 2009, 21:49:46) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import yaml
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named yaml
>>> quit()
imac:PyYAML-3.08 jjdenis$ python2.5
Python 2.5.1 (r251:54863, Feb  6 2009, 19:02:12) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import yaml
>>> quit()
imac:PyYAML-3.08 jjdenis$ 
#58 wontfix Is there a way?? xi john.mcginnis@…

Reported by john.mcginnis@…, 7 years ago.

Description
a = yaml.load("""
   name: John
   number: 111
""")

print a
{'name': 'John', 'number': 111}

ok so if I do:

print yaml.dump(a) 
{name: John, number: 11}

and

print yaml.dump(a, default_flow_style=False)
name: John
number: 111

My question is, is there a variable in the code that could make the block style the default output without having to reference the style preference all the time?

#43 fixed path resolver has bug xi jstroud@…

Reported by jstroud@…, 8 years ago.

Description

Path resolving does not work for Nodes within Sequence Nodes

[This is current for pyyaml 3.04.]

For example:

yaml.add_path_resolver(u'!MyObject', (u'myobjs', [list, False]))

should match all of the items in the myobjs sequence in this yaml:

"""
--- !MyConfig
myobjs :
    - name: x
      root: z
    - name: p
      root: q
...
"""

The problem is here in resolver.py (line 210):

elif isinstance(index_check, int):
    if index_check != current_index:
         return

If I'm infering the intent of the code correctly

(u'myobjs', (list, False))

should match all elements of the sequence keyed by "myobjs". However,

isinstance(False, int)

always returns True because bool is a subclass of int, so index_check will only equal current_index for the first element when False is specified as the index_check.


Additionally, I believe another bug exists in resolver.py. According to the code in add_path_resolver(), index_check defaults to True when not specified (resolver.py, line 39):

if isinstance(element, (list, tuple)):
    if len(element) == 2:
        node_check, index_check = element
    elif len(element) == 1:
        node_check = element[0]
        index_check = True

The intendend meaning of True here is not clear because True causes every element in the sequence to fail the match. The relevant test is in check_resolver_prefix() (resolver.py, line 116):

if index_check is True and current_index is not None:
    return

Thus, any path not specifying an index_check will never match. Most insidious to the user is that this case is never reported nor an exception thrown. If index_check is True, this code will only continue to test if current_index is None, which should never happen for any node of any sequence, because any node of a sequence must, by virtue of its existence, have an index.


To fix these problems, I propose the following patch to resolver.py:

44c44
<                     index_check = True
---
>                     index_check = False
122c122
<         elif isinstance(index_check, int):
---
>         elif isinstance(index_check, int) and index_check is not False:

This will set the default value of index_check to match all elements of a sequence if no index_check is given and will not attempt to compare False to the value of index_check.

At the bare minimum, the following patch should be strongly considered if a good reason exists to leave the defalut of index_check to True.

122c122
<         elif isinstance(index_check, int):
---
>         elif isinstance(index_check, int) and index_check is not False:

Moreover, the code should provide some indication for what an index_check value of True actually means.

In fact, I propose re-writing the code to use None to match all elements, because

isinstance(None, int)

will always evaluate to False. This will also remove the question as to what the "other" bool value means because bools will not be used. I can provide a patch if this latter proposal sounds good to the developers.

Note: See TracQuery for help on using queries.